What this application still needs to accept, and who may accept it
Returns exactly what the accept-agreements page renders: the agreements this application still owes, and the people permitted to accept them.
This exists so that page does not need GET /applications/{application_id}?include=all.
That response carries the full KYB record — the business entity, and every
associated individual’s date of birth, nationality and email address —
none of which this page displays. The link that reaches this endpoint is
emailed and travels in a URL query string, so the credential it carries
is scoped to this endpoint and the attestation submission, and cannot
read the application.
Authentication: Accepts Application Token (X-Application-Token header), including the narrow legal-acceptance token issued by a terms refusal.
Authorizations
Application-specific token for public URL access. Generated when a customer is created. Provides access to a single application without requiring an API key. Token is valid for 90 days and rate-limited to 250 requests per hour.
Path Parameters
The unique identifier for the application KSUID is a 27-character globally unique ID that combines a timestamp with a random component. Used for all entity identifiers in the Dakota platform.
27^[0-9A-Za-z]{27}$"1NFHrqBHb3cTfLVkFSGmHZqdDPi"
Response
Outstanding agreements and permitted attestors
The minimum an acceptance page needs: what is still owed, and who may sign it. Deliberately NOT the application — see the endpoint description.
Decides whether a signer is chosen or stated. A business may have several control persons; an individual application has exactly one permissible attestor, so asking them to pick themselves from a list of one is a step with no purpose.
business, individual Agreements this application has not accepted at the revision now in
force. Identity only — no document text. The bodies are served by
GET /legal/documents/{document_key}, which is cacheable and shared
with the published pages, and are ~120KB of markdown that would
otherwise ride this response.
People permitted to record an acceptance for this application. For a business this is its control persons; the API enforces the same rule on submission, so offering anyone else would only produce a 400.
What is already on file, per attestation type. The page compares each against the revision now in force to decide whether an agreement is genuinely outstanding — having signed an OLDER revision is not the same as never having signed, and the two need different copy.
Separate from outstanding_documents, which reports only documents
never accepted at all. A customer on a superseded revision appears
here and not there.

