Legal basis for signatures

Last updated Jun 14, 2026

After reading this page you'll know which rail your call traverses, which acknowledgements have to be on file before a binding mutation succeeds, why Matter is never the incorporator-of-record on the cert, and which 4xx errors fire when the legal basis is incomplete.

Why this exists

A signed Certificate of Incorporation, an issued stock grant, a dissolution filing — each one is a binding legal act. When the act is taken by software, on behalf of a human principal, every party downstream (the secretary of state, the IRS, an acquirer in due diligence, a court) needs to be able to trace the act back to a defensible legal theory.

The two rails below are that theory. They cite two federal statutes (E-SIGN Act, 15 U.S.C. §7001) and a state-level uniform act (UETA §14). They are US-only. eIDAS for EU jurisdictions is deferred until the international expansion lands.

The two signing rails

Both rails write to the same Document.signatures[] shape. The difference is the value of legal_basis on each signature entry.

{
  "signatures": [
    {
      "signer_stakeholder_id": "stk_7Hpx9WxY",
      "signed_at": 1745539180,
      "legal_basis": "esra_consent",
      "signing_session_id": "sgs_8sQp4LbR",
      "intent_text": "I, Alice Founder, agree to be bound by this Action of Incorporator.",
      "ip": "203.0.113.42",
      "user_agent": "Mozilla/5.0…"
    }
  ]
}

legal_basis is one of three values:

Rail 1 — Human signature (E-SIGN §101(c))

The human is in front of a screen. They sign by clicking a button that captures their affirmative intent.

There are two shapes for getting the human in front of the screen:

# Server kicks off the email
curl -X POST https://api.mattermode.com/v1/signing_sessions \
  -H "Authorization: Bearer $MATTER_KEY" \
  -H "Matter-Version: 2026-05-01" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "document_id": "doc_PwQ7MmLk",
    "signer_stakeholder_id": "stk_7Hpx9WxY",
    "delivery": "magic_link",
    "intent_text": "I agree to be bound by the Action of Incorporator dated 2026-04-25."
  }'

curl -X POST https://api.mattermode.com/v1/signing_sessions \
  -H "Authorization: Bearer $MATTER_KEY" \
  -H "Matter-Version: 2026-05-01" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "document_id": "doc_PwQ7MmLk",
    "signer_stakeholder_id": "stk_7Hpx9WxY",
    "delivery": "bearer",
    "intent_text": "I agree to be bound by the Action of Incorporator dated 2026-04-25.",
    "bound_clerk_user_id": "user_2nA9PqLt"
  }'

Both shapes require an ESRA disclosure. Before the signer's first electronic record, Matter presents the E-SIGN §101(c) disclosure (right to a paper copy, hardware/software requirements, withdrawal of consent, scope of the consent). The signer must affirmatively accept it via POST /v1/consents/esra. The acceptance is recorded once per signer_stakeholder_id and remains valid for 12 months unless withdrawn.

The captured intent_text is the what the signer agreed to — a plain- English sentence describing the act, generated server-side from the document's canonical metadata. It is stored verbatim alongside the signature and reproduced on every audit dump.

Rail 2 — Agent signature under UETA §14

UETA §14 ("Operation of electronic agents") provides that a contract may be formed by the interaction of electronic agents, even if no individual human reviewed each action, if the principal has authorised the agent to act on their behalf within a defined scope. Matter satisfies this authorisation requirement with a three-part chain:

The chain produces a legal_basis: "ueta_electronic_agent" signature on the resulting Document, with signed_by_agent_id populated alongside signer_stakeholder_id (the natural-person principal whose acknowledgement authorised the act). Both halves are on the receipt — that is what makes the signature defensible.

Acknowledgement slugs (the catalog)

The 12 AcknowledgementSlug enum values are the only slugs that exist. Each binds a specific class of action:

See acknowledgements for the full request shape, expiry semantics, and the GET /v1/acknowledgements catalog endpoint.

incorporator_signature_authorized — the keystone ack

Formation is the most consequential agent-driven mutation Matter offers. It is also the one that has to happen for an agent-led "form a company" flow to work without round-tripping through a human signing session.

incorporator_signature_authorized is the standing UETA §14 ack required at token creation when the token's allow[] permits entities.submit. Once on file, the agent may call POST /v1/entities/{id}/submit without a per-call human signature — the standing ack is the human's authorization for the agent to operate as their electronic agent on formation submissions.

POST /v1/entities/{id}/submit is not on the always-HITL list. This is deliberate: agent-led formation is the whole point.

Founder-as-incorporator

Matter never signs the certificate of incorporation as the named incorporator. The customer's natural-person stakeholder named at entity.incorporator_stakeholder_id does, either:

• Directly via Rail 1 — the founder clicks through a magic-link or signing-session flow.
• Through their UETA §14 electronic agent via Rail 2 — the agent invokes POST /v1/entities/{id}/submit carrying the incorporator_signature_authorized standing ack on the token, which the founder agreed to at token creation.

The legal substance is identical. The certificate names the founder as incorporator. The IncorporatorReceipt's signature_authorized_via field records which rail was used (esra_consent or ueta_electronic_agent).

This is not a Limited Power of Attorney. There is no separate POA document, no notary, no apostille. The standing ack — captured at token creation, with the founder's signer_stakeholder_id, IP, user-agent, and ESRA consent on file — is the authorization, and it is governed by UETA §14, not by the law of agency.

See incorporator protocol for how the receipt chains the founder's signature into the cryptographic proof of birth.

Where customer risk attaches

Three things are true on every binding mutation, regardless of rail:

1. Per-action acknowledgements bind specific natural-person stakeholders. accepted_by_stakeholder_id is a required field on every Acknowledgement record. The acknowledgement is the natural person's affirmative acceptance of the consequences of this specific action — not a generic ToS agreement.
2. The audit trail captures consent. Every binding mutation writes an immutable AuditEntry with the resolved acknowledgements[], the legal_basis of the resulting signature, the intent_text, the IP and user-agent of the natural-person signer (Rail 1) or the acknowledgement capture (Rail 2), and the authorized_by envelope (human_principal_id + agent_id + via).
3. Matter is a software platform, not a law firm. Every binding response carries the Disclaimer envelope. The customer is solely responsible for the legal and tax consequences of the action and should consult qualified professionals before proceeding.

The platform's role is to capture the right artifacts to defend the act later. The customer's role is to make sure the act is the right one to take.

Hard-floor HITL operations

A subset of operations have x-matter-hitl: { required: true } on the OpenAPI operation. This is a hard floor: AgentPolicy.require_human_signature_for[] and AgentPolicy.standing_acknowledgements[] cannot opt out of it. Even a tier-4 token with every standing ack on file gets a 403 human_signature_required and must escalate to a human via Rail 1.

The hard-floor list:

POST /v1/entities/{id}/submit (formation) is not on this list. The standing incorporator_signature_authorized ack at token creation is sufficient — that is the whole point of agent-led formation.

Errors

All errors follow RFC 7807. See errors for the common envelope.

Related

• Acknowledgements — the per-action ack catalog, request shape, and 90-day expiry semantics.
• Disclaimers — the disclaimer envelope on every binding response and the DisclosurePacket on dry-run.
• Incorporator protocol — how the receipt chains the founder's signature into the cryptographic proof of birth.
• Sign with a human — Rail 1 walkthrough, both Shape 1 and Shape 2.
• Sign with Claude — Rail 2 walkthrough for a tier-3 OAuth client.
• Sign as tier 4 — standing-ack flow for routine autonomous mutations.