Time	Status	User Agent
Retrieving recent requests…

Time

Status

User Agent

Retrieving recent requests…

Overview

Use this method to confirm that an applicant has already accepted the Sumsub mandatory consents in your own interface, before the verification starts.

This method is the recommended way to record consents in API-only integrations and in any flow where consent is collected outside the SDK.

Two documents are always recorded, for every applicant, regardless of their country:

This mirrors the SDK consent screen, which presents both documents together.

Notes

Once the acceptance is recorded, a WebSDK or MobileSDK session started for this applicant skips the consent screen. The same applies to applicant actions.

You can also add accepted applicant consents when creating an applicant, provided you upload the relevant documents.

Attention
Custom consents are not covered. If a custom consent (your own text or link) is configured on the level, it is not recorded by this method, and the SDK does not ask for it after an acceptance is recorded. Collect and store such consents in your own interface.

Required permissions

To use this method, your app token must have the View applicants permission.

The method works only with app token authentication. SDK access tokens are not accepted.

Request example

curl -X POST \
     'https://api.sumsub.com/resources/applicants/5b7e4e62d2b4bc00b5a0b4a5/acceptedAgreements' \
     -H 'Content-Type: application/json' \
     -H 'X-App-Token: <your-app-token>' \
     -H 'X-App-Access-Sig: <your-signature>' \
     -H 'X-App-Access-Ts: <unix-timestamp>' \
     -d '{
           "acceptedAt": "2026-03-01 10:00:00+0000",
           "ip": "203.0.113.7"
         }'

Response explained

If the request is successfully sent and processed, you will get the 200 HTTP status and the applicant object. The recorded acceptance appears in agreement.items.

The following table explains the fields of the recorded consent entry.

Field	Type	Description
`id`	String	Unique identifier of the consent entry.
`acceptedAt`	Date	The value you submitted, converted to GMT.
`createdAt`	Date	Date and time (GMT) when Sumsub received and stored the acceptance.
`ip`	String	The value you submitted.
`source`	String	`API` for consents recorded with this method.
`type`	String	`onboarding`.
`recordIds`	Array of strings	Identifiers of the two stored consent documents.

To read the acceptance back together with the consent texts, use Get applicant-facing consents.

Note
Sending the same acceptance again does not create a second entry. A new entry is added only when the recorded documents differ from the ones already accepted — for example, when the applicant had previously accepted a different set of consents in the SDK.

Response example

The response example below is shortened to the relevant fields. The full applicant object is described on the Get applicant data page.

{
  "id": "5b7e4e62d2b4bc00b5a0b4a5",
  "createdAt": "2026-03-01 09:58:11",
  "agreement": {
    "items": [
      {
        "id": "0f2d4bfe-02b7-4f69-9a39-7d1b8f21c0a7",
        "createdAt": "2026-03-01 10:00:42",
        "acceptedAt": "2026-03-01 10:00:00",
        "source": "API",
        "type": "onboarding",
        "ip": "203.0.113.7",
        "recordIds": [
          "67c1f0a9bf2c1a0012ab34cd",
          "67c1f0a9bf2c1a0012ab34ce"
        ]
      }
    ]
  }
}

If the request fails, you will receive an HTTP response containing an error code along with a message explaining the error.

Possible errors

The following table lists the possible errors.

HTTP code	Description
`400`	`acceptedAt` is missing, is not in the `yyyy-MM-dd HH:mm:ss+hhmm` format, is in the future, or is earlier than `2000-01-01`.
`400`	`ip` is missing, empty, or is not a valid IPv4 or IPv6 address.
`400`	The request body is empty.
`403`	The app token does not have the View applicants permission.
`404`	The applicant does not exist.