Record that the account owner accepted one of the account terms
Records the owner’s acceptance of one document from the terms an account would be opened under. The documents, their slug, the version to acknowledge and the exact wording each acceptance stands for come from GET /v1/virtual-accounts/requirements, whose disclosure.acknowledgement requirement lists every outstanding document with this call as its acknowledgePath. The acceptance is recorded against the owner’s application before or after its approval. Idempotent per document; acknowledging again at a newer version updates the record in place. Acknowledging with an API key attests that the owner accepted in your own flow, so attestation is required there and carries the evidence (when they accepted, from which IP and user agent, and who signed). A dashboard session records the signed-in user’s own click and sends no attestation.
Authorizations
Enter Auth0 JWT token
Headers
Optional. Names an owned sub-account (UUID); when present, the application must belong to it. Omit to act on any application in your workspace. Naming an account this key does not own returns 403 not_account_owner.
Path Parameters
The document’s slug as the requirements response names it.
"terms-of-service"
Body
Response
"2026-08-07T10:22:33.123Z"
Which surface recorded this acknowledgment. An api_key row always carries a complete attestation; a dashboard_user row never does, because the signed-in click is itself the evidence. null names a row that asserts neither, so a missing attestation is never ambiguous.
dashboard_user, api_key UUID of the ack row.
The acceptance evidence recorded with this acknowledgment, or null when the owner acknowledged in the Zuba dashboard themselves.