Events

Last updated Jun 14, 2026

Mutations return 202 Accepted. Terminal outcomes — entity registered, filing accepted, dissolution complete — arrive minutes to days later as Event objects. The event stream is the source of truth; webhooks are one delivery mechanism on top of it.

Every state-changing action produces an Event that flows through two delivery mechanisms:

• Webhooks — HTTP POST to a URL you register, signed with HMAC-SHA256.
• Server-Sent Events — GET /events/stream for live in-process subscription, useful for dashboards and agent observability.

Each event carries:

{
  "id": "evt_2026apr24_184217_42",
  "type": "filing.accepted",
  "occurred_at": "2026-04-24T18:42:17Z",
  "subject": {"object": "filing", "id": "flg_q1_franchise_tax"},
  "sequence": 4218,
  "authorized_by": {
    "human_principal_id": "usr_dom",
    "agent_id": "ai-paralegal-v2"
  },
  "data": { /* the resource snapshot, only when WebhookEndpoint.include = ["data.object"] */ }
}

Strict per-subject ordering

Events have a monotonically-increasing sequence number scoped to each subject (entity, filing, grant, etc.). Webhook delivery preserves this ordering — your endpoint will never receive filing.accepted before the matching filing.submitted for the same filing. Cross-subject ordering is best-effort.

Thin vs fat payloads

By default, payloads are thin: just the subject's id and object_type. To receive the full resource snapshot inline, set WebhookEndpoint.include = ["data.object"] at registration. Thin payloads are cheaper to deliver and re-fetching gives you the canonical current state — fat payloads are convenient when your handler doesn't have the credentials to re-fetch.

Webhooks retry for 3 days in live mode.

Related

• Webhooks — endpoint registration, signature verification, replay.
• Audit — the queryable historical record, paired with the event stream.
• GET /events
• GET /events/stream