Last updated Jun 14, 2026

Adjacent integrations

Matter is one platform in a complex stack. Some surfaces are pure Matter — formation, governance, equity, dissolution. Others overlap with partners where Matter coordinates and a partner may execute. Others are partner-primary with thin Matter records. Others are pure partners with clean handoff webhooks. Some are out-of-scope entirely.

This page is the consolidated index. It names every adjacent partner integration the platform recognises, the ring it sits in, the data Matter exposes, the data the partner returns, the webhook that fires, and the closure pattern. Cookbook recipes and other convention pages cross-link here for partner-by-partner detail.

Ring 1 — Core (Matter operates end-to-end)

Ring 1 is everything Matter operates as primary. No partner is on the critical path; the entity, its governance, its equity, its registered agent, and its dissolution all flow through Matter resources end-to-end. A handful of jurisdictional executions (the secretary of state itself, the IRS for EIN, FinCEN for BOI) are not "partners" — they are the legal counterparties Matter files against.

Ring 2 — Adjacent-core (Matter coordinates; partners may execute)

Ring 2 is where Matter owns the workflow and the calendar, but a partner may carry out the underlying execution. Compliance calendars are Matter; the actual filing may be Matter (BOI direct-to-FinCEN), the registered agent (annual report), or a tax filer (franchise tax). The cap-table is Matter's source of truth, but founders may also subscribe to a Carta or Pulley portal that syncs against Matter's ledger.

Ring 3 — Adjacent-extend (Matter could integrate; white-label optional)

Ring 3 is where Matter records the existence of an artifact even though the partner authors and executes the substance. Matter's role is to attach the policy, the opinion, the study, the registration to the entity ledger so the audit trail is complete. The white-label question — does Matter render the partner's flow inside Matter's UI, or simply link out — is settled per partner, not per ring.

Ring 4 — Partner-handoff (Matter records existence and obligations; partner runs flow)

Ring 4 is where Matter does not own the product surface. A payroll provider runs payroll. A bank holds money and originates wires. A bookkeeping firm closes the books. Matter records that the partnership exists, captures the corresponding attestation Document, and writes the recurring obligations to the compliance calendar — but the partner's product is the operational truth. The handoff is a webhook in each direction.

Ring 5 — Out-of-scope (Matter never does)

Ring 5 is the explicit non-list. Matter is the entity-as-object surface; these domains do not intersect with that surface and Matter does not build into them. Founders use Matter alongside specialists for these.

• General counsel substitution.
• M&A advisory (the envelope state machine and the post-Exit Manage windows are Matter; banker work is not).
• Fundraising introductions, investor matchmaking, demo days.
• Tax advice for individuals — founder personal taxes, RSU planning, exit planning for the human.
• Immigration (O-1, EB-1, E-2, L-1).
• Real-estate eRecording, fund administration, capital-markets services, trustee services.

Webhook patterns

Every Ring 3 and Ring 4 integration follows the same webhook pattern. Matter publishes outgoing webhooks per the WebhookEndpoint resource; partners publish back to Matter via signed inbound webhooks. The inbound webhook flips state on the relevant Matter resource — Filing.status: accepted, BankAccount.status: opened, Document.execution_status: executed — and Matter then propagates the state change as a normal outgoing event to subscribers.

   ┌──────────────────────┐                     ┌──────────────────────┐
   │       Matter         │   outbound event    │       Partner        │
   │  - Resource record   │ ──────────────────▶ │  - Account, policy,  │
   │  - Attestation Doc   │                     │    plan, study       │
   │  - Calendar entry    │ ◀────────────────── │  - Operational flow  │
   └──────────────────────┘   inbound webhook   └──────────────────────┘
              │                                            │
              │              flip resource state           │
              ▼                                            ▼
   ┌──────────────────────┐                     ┌──────────────────────┐
   │     Outbound event   │                     │     Partner ack      │
   │  filing.accepted     │                     │  Form 941 filed      │
   │  bank_account.opened │                     │  Plan terminated     │
   │  policy.bound        │                     │  Account closed      │
   └──────────────────────┘                     └──────────────────────┘

Per-entity strict ordering applies in both directions. See webhook ordering for the contract.

Cross-ring movements

The framework is structural, not static. Domains move between rings as the product surface grows or contracts. The bar for moving a domain toward Matter (toward Ring 1) is high — Matter takes on operational ownership only when the entity-as-object framing genuinely demands it. The bar for moving outward (toward Ring 5) is also high — once a domain is in the ledger, removing it strands existing entities. Most domains are stable in their current ring.

Past movements:

• 401(k) plan attestation moved from Ring 5 (out-of-scope) to Ring 3 in Sprint D, when the BenefitPlan resource and benefit_plan_attestation Document.kind landed. The trigger was the dissolution cascade — plan termination is a board-authorised act, and the attestation was needed to anchor the resolution to the record-keeper.
• State employer registrations moved from Ring 4 (full handoff to payroll providers) to Ring 2 in Sprint A, when StateRegistration became a first-class resource. Payroll providers still execute withholding, but Matter owns the registration's open/close state and the calendar of statutory filings.

Proposed movements:

• Insurance policy linkage is proposed to move from Ring 4 to Ring 3 when the Document.kind: insurance_policy enum lands. Matter would record the policy number, the carrier, and the termination notice — the carrier still executes coverage and adjudicates claims.
• Cap-table employee portal UX is unlikely to move. The cap-table itself is Ring 2 (Matter operates), but the employee-facing portal — password reset, equity statement download, exercise UI — is partner product surface. Matter syncs the data; the partner renders.

A movement proposal must justify (a) why the new ring better serves existing entities, (b) what new resources or attestation Documents are required, and (c) what migration path applies to entities already in the ledger.

Adding a new partner integration

When a new adjacent integration comes up, the design pattern is:

1. Identify the ring. Is this Ring 3 (Matter records the artifact, white-label optional) or Ring 4 (Matter does not own the product surface)? If neither, the proposal is probably Ring 5 — restate it as a non-integration.
2. Identify the partner-side resource. What does the partner expose — an account, a policy, a plan, a study? Name the partner resource so the linkage is unambiguous.
3. Identify the Matter-side records. What Document.kind, first-class Resource, or attestation captures the partnership? If nothing exists, propose the new enum value or resource alongside the integration.
4. Identify the webhook. Inbound from partner — what state change does it trigger on Matter's resource? Outbound from Matter — what event do subscribers receive when the state flips?
5. Identify the closure event. When does the partnership end — account closure, policy termination, plan dissolution, study completion? Matter exposes a closure verb that records intent and captures the partner's acknowledgement Document.

If a proposal cannot be expressed in those five buckets without inventing a recurring-flow resource on Matter's side, it crosses the line into Ring 1 territory and needs explicit product justification.

Related

• Payroll and benefits handoff — Ring 4 specific to employment and benefits.
• Post-Exit Manage — a Ring 4 and Ring 3 hybrid for post-Exit obligations.
• Templates — separate boundary about template provenance.
• Lifecycle — the broader Create / Manage / Exit framing every ring fits inside.