generated: '2026-09-09'
method: derived
source: https://docs.advicepay.com/#schemas
note: >-
  Derived from the Schemas section of the published AdvicePay reference (44 schemas) and the
  id-reference fields carried on each resource. AdvicePay publishes no OpenAPI, so this graph was
  read from the documented property tables rather than from $ref links in a spec; relationships
  are inferred from the <entity>ID foreign-key fields the docs describe, and each is labelled with
  the field it travels on so a reader can verify it.
identifiers:
  format: integer
  prefixes: none
  note: >-
    Ids are plain integers with no type prefix, so an id is not self-describing — a bare 42 could
    be an invoice, a client or an office. Cross-references are named <entity>ID.
external_ids:
  supported: true
  fields:
  - externalID
  - advisorExternalID
  - clientExternalID
  - externalUserID
  - externalEngagementID
  - ssoID
  note: >-
    Most core entities carry an externalID (and several carry counterpart-scoped variants), which
    is the documented hook for keying AdvicePay records to a firm's CRM or book-of-record. ssoID
    links a user to an external identity provider for SAML SSO.
entities:
- name: User
  schema: User
  description: Base identity record; specialised as Admin and Advisor.
  operations: [GET /api/public/v1/me]
- name: Admin
  schema: Admin
  collection: /api/public/v1/admins
  operations: [List, Create, Get, Update, Delete]
- name: Advisor
  schema: Advisor
  collection: /api/public/v1/advisors
  operations: [List, Create, Get, Update, Delete]
- name: Office
  schema: Office
  collection: /api/public/v1/offices
  operations: [List, Create, Get, Update]
  note: Offices nest — an Office carries parentID, forming the firm hierarchy.
- name: Client
  schema: Client
  collection: /api/public/v1/clients
  operations: [List, Create, Get, Update]
  note: No delete operation is published for clients.
- name: Engagement
  schema: Engagement
  collection: /api/public/v1/engagements
  operations: [List, Get, GetRevenue, GetSummary, ListSummaries]
  note: Read-only over the API; engagements are created in the application.
- name: Agreement
  schema: Agreement
  collection: /api/public/v1/agreements
  operations: [List, Get, Download]
  note: Read-only. Download is the endpoint carrying the 1 req/sec rate limit.
- name: Invoice
  schema: Invoice
  collection: /api/public/v1/invoices
  operations: [List, Create, Get, DownloadPDF, Refund]
- name: Subscription
  schema: Subscription
  collection: /api/public/v1/subscriptions
  operations: [List, Create, Get]
  note: No cancel or delete operation is published — see conventions reversibility block.
- name: Transfer
  schema: Transfer
  collection: /api/public/v1/transfers
  operations: [List]
  note: Payouts to the firm's bank account; read-only.
- name: Transaction
  schema: Transaction
  note: Individual money movements composing a Transfer. No standalone collection endpoint.
- name: Deliverable
  schema: Deliverable
  collection: /api/public/v1/deliverables
  operations: [List, Create, Get, Update, Submit, GetUploadURL, DownloadFile]
- name: DeliverableTemplate
  schema: DeliverableTemplate
  collection: /api/public/v1/deliverable_templates
  operations: [List, Create, Get, Update]
- name: Notification
  schema: Notification
  collection: /api/public/v1/notifications
  operations: [List]
  note: The only change-feed surface; polled with createdAfter/createdBefore. No webhooks exist.
- name: CustomAttribute
  schema: CustomAttribute
  collections: [/api/public/v1/client_attributes, /api/public/v1/advisor_attributes]
  operations: [List]
- name: eSignTemplate
  schema: eSignTemplate
- name: Signer
  schema: Signer
- name: ServiceDescription
  schema: ServiceDescription
- name: EngagementRevenue
  schema: EngagementRevenue
- name: EngagementSummary
  schema: EngagementSummary
- name: AdvancedSplitRepCode
  schema: AdvancedSplitRepCode
- name: DeliverableEvidence
  schema: DeliverableEvidence
relationships:
- from: Invoice
  to: Client
  type: belongs_to
  via: clientID
- from: Invoice
  to: Advisor
  type: belongs_to
  via: advisorID
- from: Invoice
  to: Engagement
  type: belongs_to
  via: engagementID
- from: Invoice
  to: Subscription
  type: belongs_to
  via: subscriptionID
  note: Populated when the invoice was generated by a recurring subscription rather than created one-off.
- from: Invoice
  to: ServiceDescription
  type: has_many
  via: serviceDescriptions
- from: Invoice
  to: AdvancedSplitRepCode
  type: has_many
  via: advancedSplitRepCodes
- from: Subscription
  to: Client
  type: belongs_to
  via: clientID
- from: Subscription
  to: Advisor
  type: belongs_to
  via: advisorID
- from: Subscription
  to: Engagement
  type: belongs_to
  via: engagementID
- from: Subscription
  to: Invoice
  type: has_many
  via: subscriptionID
  note: Inverse of Invoice.subscriptionID — the recurring invoices a subscription generates.
- from: Engagement
  to: Client
  type: belongs_to
  via: clientID
- from: Engagement
  to: Advisor
  type: belongs_to
  via: advisorID
- from: Engagement
  to: Agreement
  type: has_one
  via: primaryAgreementID
- from: Engagement
  to: Deliverable
  type: has_many
  via: engagementID
- from: Engagement
  to: EngagementRevenue
  type: has_one
  via: GET /api/public/v1/engagements/{id}/revenue
- from: Engagement
  to: EngagementSummary
  type: has_one
  via: GET /api/public/v1/engagements/{id}/summary
- from: Agreement
  to: Client
  type: belongs_to
  via: clientID
- from: Agreement
  to: Advisor
  type: belongs_to
  via: advisorID
- from: Agreement
  to: Signer
  type: has_many
  via: signers
- from: Agreement
  to: eSignTemplate
  type: has_one
  via: eSignTemplate
- from: Client
  to: Advisor
  type: belongs_to
  via: advisorID
- from: Client
  to: CustomAttribute
  type: has_many
  via: customAttributes
- from: Advisor
  to: Office
  type: belongs_to
  via: officeID
- from: Advisor
  to: CustomAttribute
  type: has_many
  via: customAttributes
- from: Advisor
  to: Client
  type: has_many
  via: advisorID
- from: Office
  to: Office
  type: belongs_to
  via: parentID
  note: Self-referential — offices form a tree, which is how enterprise home offices model branches.
- from: Office
  to: Advisor
  type: has_many
  via: officeID
- from: Deliverable
  to: DeliverableTemplate
  type: belongs_to
  via: templateID
- from: Deliverable
  to: Engagement
  type: belongs_to
  via: engagementID
- from: Deliverable
  to: DeliverableEvidence
  type: has_many
  via: evidence
- from: Transfer
  to: Transaction
  type: has_many
  via: transactions
- from: Transaction
  to: Invoice
  type: belongs_to
  via: invoiceID
- from: Notification
  to: Advisor
  type: belongs_to
  via: advisorID
- from: Notification
  to: Client
  type: belongs_to
  via: clientID
core_flow: >-
  Office -> Advisor -> Client is the tenancy spine. An Advisor and a Client meet in an Engagement,
  which is backed by an Agreement (eSigned by Signers) and produces Deliverables. Billing hangs off
  the Engagement: either a one-off Invoice or a Subscription that generates Invoices on a cadence.
  Money collected settles into Transfers, each composed of Transactions that point back at the
  Invoices they paid. Notifications is the flat, pollable audit feed across all of it.
schema_count: 44