> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clemta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Company document received

> Sent when an individual owner uploads their identity document. The request body is the `event` resource. Fetch the company it names to see which owners are still outstanding. When the last document lands, the company also emits `company.status.changed`. Verify the `Clemta-Webhook-Signature` header before trusting the payload, and respond with any 2xx to acknowledge - a non-2xx or a timeout is retried with backoff.



## OpenAPI

````yaml /partner/openapi.yaml webhook company.document.received
openapi: 3.1.0
info:
  title: Clemta Partner API
  description: |
    The Clemta partner surface. Authenticate with your API key as a bearer
    token (`Authorization: Bearer clmt_live_` or `clmt_test_`). Keys with
    the `clmt_test_` prefix operate in sandbox mode (`livemode: false`): test
    data never reaches fulfillment or billing.

    Versioning is date-based: pass `Clemta-Version` to pin a
    version, omit it to run on your account's pinned default. The effective
    version is echoed back on every response.
  version: '2026-08-13'
servers:
  - url: https://api.clemta.com/v1
    description: >
      Single host for both modes: `clmt_test_` keys operate in sandbox mode,
      `clmt_live_` keys in live mode.
security:
  - apiKey: []
tags:
  - name: Identity
    description: Identify the calling API key.
  - name: Accounts
    description: >-
      Create and read customer accounts - the incorporators companies are
      created under.
  - name: Companies
    description: Create and read client companies.
  - name: Service orders
    description: Order services against a company and follow their fulfilment.
  - name: Products
    description: The catalog you can offer, at your wholesale prices.
  - name: Tax filings
    description: >-
      Federal and state tax filings on your companies, opened by your client
      against the company's entitlements and worked by Clemta. Read-only. Follow
      them with the tax_filing.* events.
  - name: Files
    description: >-
      Documents Clemta publishes on your companies - formation deliverables,
      filed forms, letters. Read-only. Client KYC uploads are write-only and
      never listed.
  - name: Requirements
    description: >-
      Everything needed from you or your client - identity documents,
      service-order forms, Clemta's asks - as one resolvable resource. Fulfill
      over the API or hand your client a hosted link.
  - name: Status tracking
    description: >-
      End-customer status links - keyless, read-only access to a company's live
      status.
  - name: Events
    description: Poll the partner event stream.
  - name: Webhooks
    description: >-
      Events we deliver to your endpoint, and how to verify them. Each webhook
      below is a request WE send to you. Respond 2xx to acknowledge. Deliveries
      are signed and retried with exponential backoff over multiple days until
      acknowledged. Answer `410 Gone` to have the endpoint disabled and
      deliveries stopped. A `Retry-After` header on a `429` or `503` pushes the
      next attempt back. An endpoint that fails continuously for days is
      disabled automatically and the workspace owner is emailed - no events are
      lost, the stream stays available on `GET /v1/events`.


      ## Verifying a delivery


      Deliveries are signed per the [Standard
      Webhooks](https://www.standardwebhooks.com) specification, carrying BOTH
      schemes in one header: a symmetric `v1` HMAC (verify with your endpoint
      secret and any standardwebhooks library) and an asymmetric `v1a` ed25519
      signature (verify with the endpoint's public key, no shared secret held).
      Use whichever suits your setup.


      Every endpoint has its OWN signing secret (`whsec_...`), shown once when
      you create the endpoint. Each delivery carries three headers:


      - `Clemta-Webhook-Id` - the event id. Stable across retries: use it as an
      idempotency key so a redelivered event is processed once.

      - `Clemta-Webhook-Timestamp` - unix seconds of THIS attempt (a retry
      carries a fresh one).

      - `Clemta-Webhook-Signature` - a space-delimited list of `v1,<base64>`
      signatures. More than one while a secret rotation's overlap window is
      open, one per active secret.


      Each is also sent under its bare Standard Webhooks name (`webhook-id`,
      `webhook-timestamp`, `webhook-signature`) with the same value, which is
      what off-the-shelf standardwebhooks libraries look up.


      To verify by hand:


      1. Build the signed content by joining the id, the timestamp, and the raw
      request body with literal `.` separators: `{id}.{timestamp}.{body}`. Use
      the body exactly as received - do not re-serialize the JSON.

      2. Base64-decode your endpoint secret after the `whsec_` prefix. That is
      the HMAC key.

      3. Compute HMAC-SHA256 over the signed content, base64 encode it, and
      compare it against each `v1,` entry in constant time. Accept if any
      matches, otherwise reject.

      4. Check the timestamp is within 5 minutes of now, to reject replays.


      Because the secret is unique to your endpoint, a signature can only be
      verified by you - a delivery meant for another endpoint cannot be made to
      verify here. Keep the secret confidential. If it leaks, roll the
      endpoint's secret from the Webhooks page of your partner dashboard.
  - name: Sandbox
    description: >-
      Test-key-only endpoints for rehearsing event flows. Trigger a lifecycle
      transition on a test company and receive the matching webhook, without
      waiting for a real formation to progress.
paths: {}
components:
  securitySchemes:
    apiKey:
      type: http
      scheme: bearer
      description: >
        Your API key, e.g. `Authorization: Bearer clmt_test_`. Live keys use the
        `clmt_live_` prefix.

````