---
title: "Create a verification"
method: POST
path: "/verifications"
tags: ["Verifications"]
---

# Create a verification

`POST /verifications`

Creates a verification. Available and mandatory fields depend on the type of client, country, and industry.
The service returns a **verification ID** for use with Payins and Payouts APIs.

**Wire format:** the endpoint accepts `multipart/form-data` with a string field `body` whose value is a JSON string with the **same** structure as the `application/json` body below, and optional `file` parts (use filenames such as `DOCUMENT_FRONT` and `DOCUMENT_BACK` where required). The JSON body below is the reference shape; stringify it to populate the `body` part when using multipart.

**Notifications:** status updates will be sent to the `notification_url` provided in the request. See the **Callbacks** section below and the [Verifications notifications](https://docs.dlocal.com/reference/verifications-notifications) guide for the retries policy and signature recipe.

## Request body

- union
  - CreateRemitterVerification
    - `type` 'REMITTANCE', required — Remittance verification — the allowed value is `REMITTANCE`.
    - `notification_url` string, uri — URL where dLocal will send notifications for verification status changes.
    - `attributes` object, required — Remitter flow — `client.type` is always `REMITTER` in this shape.
      - `client` object, required
        - `type` 'REMITTER', required
    - `file` string[] — File with the content of the document to update. Each file name must include an extension, which can be either `.jpeg`, `.png`, or `.pdf`. <br><br> `DOCUMENT_FRONT` and `DOCUMENT_BACK`. Please [refer to the list of acceptable documents](https://docs.dlocal.com/reference/document-information#document-names).
  - CreateBeneficiaryVerification
    - `type` 'REMITTANCE', required — Remittance flow — the allowed value is `REMITTANCE` (same as remitter).
    - `notification_url` string, uri — URL where dLocal will send notifications associated with verification status changes. See [Verifications notifications](https://docs.dlocal.com/reference/verifications-notifications) for the payload contract.
    - `attributes` object, required — Beneficiary flow — `client.type` is `BENEFICIARY` for this oneOf branch.
      - `client` object, required
        - `type` 'BENEFICIARY', required
    - `file` string[] — Optional file parts when the flow requires document uploads. Each file name must include an extension (`.jpeg`, `.png`, or `.pdf`). Please [refer to the list of acceptable documents](https://docs.dlocal.com/reference/document-information#document-names).
  - CreateStandaloneVerification
    - `type` 'STANDALONE', required
    - `notification_url` string, uri — URL where dLocal will send notifications associated with verification status changes. See [Verifications notifications](https://docs.dlocal.com/reference/verifications-notifications) for the payload contract.
    - `attributes` object, required — Standalone — `client` must include document fields (`document_type`, `document_number`, `document_country`).
      - `external_reference` string — ID given by the merchant in their system.
      - `client` object, required
        - `type` 'BENEFICIARY', required — For standalone verifications the client type is `BENEFICIARY`.
        - `document_type` 'TAX_ID', required — Client's document type. For standalone verifications the value is `TAX_ID`.
        - `document_number` string, required — Client's document number.
        - `document_country` string, required — Client's document country. Format ISO 3166-1 alpha-2 code.

## Response `200`

Successful response

- Verification — Verification resource. Shape depends on `type` and flow (e.g. remittances, payouts on hold, payins on hold, standalone). For `PAYOUTS_ON_HOLD` / `PAYINS_ON_HOLD`, `attributes.external_reference` is often the related payout or payin id. Use `include=client_data` on GET when you need the nested `attributes.client` object. **Status (illustrative):** e.g. `CREATING`, `PENDING` (with details such as documentation, compliance review, or resubmit), `APPROVED`, `REJECTED`, `EXPIRED`, `ERROR`. The pair `status` + `status_detail` (and `status_code` when present) describes the current step in the process.
  - `type` string — Flow discriminator. Remittance verifications use `REMITTANCE`. Other examples include `STANDALONE`, `PAYOUT_ON_HOLD`, and `PAYINS_ON_HOLD` — use values provided by dLocal for your agreement.
  - `id` string — dLocal verification ID in UUID format.
  - `notification_url` string, uri — URL where dLocal will send notifications associated with verification status changes. See [Verifications notifications](https://docs.dlocal.com/reference/verifications-notifications) for the payload contract.
  - `created_date` string — Creation timestamp (e.g. `YYYY-MM-DDTHH:mm:ss` with optional fractional seconds).
  - `expiration_date` string — Expiration when applicable; may be empty.
  - `status` string — Verification status. [See details](https://docs.dlocal.com/reference/verification-status).
  - `status_detail` string — Verification status detail. [See details](https://docs.dlocal.com/reference/verification-status).
  - `status_code` union — Verification status code. [See details](https://docs.dlocal.com/reference/verification-status).
    - string
    - integer
  - `attributes` object — Commonly includes `external_reference` and, when `include=client_data` is used, `client` (beneficiary, remitter, payer, etc.) and related nested objects.

## Other responses

- `400` — Bad request — invalid format or validation error
- `401` — Unauthorized — invalid credentials
- `403` — Forbidden — authentication failed or unauthorized access
- `500` — Internal server error

---

[API](https://skmtc.net/dlocal/apis/payins.md) · [All operations](https://skmtc.net/dlocal/apis/payins/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/dlocal/payins/revisions/d87e090020f9/schema)