Submit Onboarding Form

Endpoint

POST /v3/onboarding/{onboarding_requisition_id}/submit

This is the last step of the own-form flow. It comes after POST /v3/onboarding/form and, when the onboarding requires the proof of life, after the end user has passed the liveness. It can only be called once per onboarding requisition.

The response is returned as soon as the payload is accepted and stored — it does not mean the onboarding was approved. The analysis runs in background; keep polling the onboarding status endpoint (GET /v3/onboarding/10482) until current_step becomes DONE.

Headers

Path Parameters

Body Details

{
  "company": {
    "official_name": "Example Company LTDA",
    "fantasy_name": "Example Company",
    "company_email": "finance@example.com",
    "phone_number": "11999998888",
    "opening_date": "2015-03-10",
    "zip_code": "01310100",
    "state": "SP",
    "city": "Sao Paulo",
    "street": "Avenida Paulista",
    "neighborhood": "Bela Vista",
    "number": "1000",
    "complement": "12th floor"
  },
  "partners": [
    {
      "name": "Joao da Silva",
      "cpf": "11144477735",
      "birth_date": "1988-07-21",
      "mother_name": "Maria da Silva",
      "ownership_pct": 100,
      "is_legal_representative": true
    }
  ],
  "documents": [
    {
      "type": "RG_FRONT",
      "partner_cpf": "11144477735",
      "filename": "id-front.jpg",
      "mime_type": "image/jpeg",
      "content": "iVBORw0KGgoAAAANSUhEUgAA..."
    },
    {
      "type": "COMPANY_SOCIAL_CONTRACT",
      "partner_cpf": null,
      "filename": "social-contract.pdf",
      "mime_type": "application/pdf",
      "content": "JVBERi0xLjQKJeLjz9MK..."
    }
  ],
  "accepted_terms": true
}

company

Every field of the company object is individually optional — send what your form collected. The object itself is required for PJ onboarding.

partners

Each item of the partners array describes one person declared in the form.

documents

Each item of the documents array carries one file encoded in base64.

Document types:

Front and back also accept the aliases below. They are stored as IMAGE_FRONT or IMAGE_BACK; the rest of the rules (partner_cpf, mandatory front per partner) apply to the mapped type. An unknown value is rejected with 400.

Request Examples

PJ onboarding (company with two partners):

POST /v3/onboarding/10482/submit
X-Onboarding-Token: 8bR3xTqZ0pW7yLm2nV4cJdH6sKfA1gQeUoI9tXyZbCk
Content-Type: application/json

{
  "company": {
    "official_name": "Example Company LTDA",
    "fantasy_name": "Example Company",
    "company_email": "finance@example.com",
    "phone_number": "11999998888",
    "opening_date": "2015-03-10",
    "zip_code": "01310100",
    "state": "SP",
    "city": "Sao Paulo",
    "street": "Avenida Paulista",
    "neighborhood": "Bela Vista",
    "number": "1000",
    "complement": "12th floor"
  },
  "partners": [
    {
      "name": "Joao da Silva",
      "cpf": "111.444.777-35",
      "birth_date": "1988-07-21",
      "mother_name": "Maria da Silva",
      "father_name": "Jose da Silva",
      "rg": "123456789",
      "rg_issuing_authority": "SSP",
      "rg_issue_state": "SP",
      "rg_issue_date": "2010-02-15",
      "birth_place": "Sao Paulo",
      "birth_state": "SP",
      "nationality": "Brazilian",
      "email": "joao.silva@example.com",
      "phone_number": "11988887777",
      "ownership_pct": 60,
      "is_legal_representative": true
    },
    {
      "name": "Ana Souza",
      "cpf": "529.982.247-25",
      "birth_date": "1991-11-02",
      "mother_name": "Clara Souza",
      "email": "ana.souza@example.com",
      "phone_number": "11977776666",
      "ownership_pct": 40,
      "is_legal_representative": false
    }
  ],
  "documents": [
    {
      "type": "RG_FRONT",
      "partner_cpf": "111.444.777-35",
      "filename": "joao-id-front.jpg",
      "mime_type": "image/jpeg",
      "content": "iVBORw0KGgoAAAANSUhEUgAA..."
    },
    {
      "type": "RG_BACK",
      "partner_cpf": "111.444.777-35",
      "filename": "joao-id-back.jpg",
      "mime_type": "image/jpeg",
      "content": "iVBORw0KGgoAAAANSUhEUgBB..."
    },
    {
      "type": "IMAGE_FRONT",
      "partner_cpf": "529.982.247-25",
      "filename": "ana-id-front.jpg",
      "mime_type": "image/jpeg",
      "content": "iVBORw0KGgoAAAANSUhEUgCC..."
    },
    {
      "type": "COMPANY_SOCIAL_CONTRACT",
      "partner_cpf": null,
      "filename": "social-contract.pdf",
      "mime_type": "application/pdf",
      "content": "JVBERi0xLjQKJeLjz9MK..."
    },
    {
      "type": "OTHER",
      "partner_cpf": null,
      "filename": "proof-of-address.pdf",
      "mime_type": "application/pdf",
      "content": "JVBERi0xLjQKJeHqz9MK..."
    }
  ],
  "accepted_terms": true
}

PF onboarding (individual, no company object):

POST /v3/onboarding/10483/submit
X-Onboarding-Token: 4kQ2wYpN8zR1vBc6mXsLd0TgHj7fEa3UiOy5nPzWqRs
Content-Type: application/json

{
  "partners": [
    {
      "name": "Joao da Silva",
      "cpf": "111.444.777-35",
      "birth_date": "1988-07-21",
      "mother_name": "Maria da Silva",
      "rg": "123456789",
      "rg_issuing_authority": "SSP",
      "rg_issue_state": "SP",
      "birth_place": "Sao Paulo",
      "birth_state": "SP",
      "nationality": "Brazilian",
      "email": "joao.silva@example.com",
      "phone_number": "11988887777",
      "ownership_pct": 100,
      "is_legal_representative": true
    }
  ],
  "documents": [
    {
      "type": "IMAGE_FRONT",
      "partner_cpf": "111.444.777-35",
      "filename": "id-front.jpg",
      "mime_type": "image/jpeg",
      "content": "iVBORw0KGgoAAAANSUhEUgAA..."
    },
    {
      "type": "IMAGE_BACK",
      "partner_cpf": "111.444.777-35",
      "filename": "id-back.jpg",
      "mime_type": "image/jpeg",
      "content": "iVBORw0KGgoAAAANSUhEUgBB..."
    }
  ],
  "accepted_terms": true
}

Response Details

HTTP 202 Accepted

{
  "worked": true,
  "onboarding_requisition_id": 10482,
  "submitted_at": "2026-09-15T18:42:07.512000Z"
}

202 Accepted means the payload was validated, stored and accepted for analysis — it is not an approval. From this point the requisition moves to current_step: PROCESSING; poll the onboarding status endpoint (GET /v3/onboarding/10482) until current_step becomes DONE and read status_internal (APPROVED or REJECTED) for the final outcome.

Error Responses

Business Rules

Preconditions:

• The requisition must use the platform form. One created for the provider-hosted journey is rejected with 412 (Onboarding does not use the platform form.).
• When the requisition requires liveness, it must have passed. While liveness_status is PENDING or FAILED, the call is rejected with 412. A requisition configured without liveness skips this check and carries a SELFIE per partner instead.
• The form can be submitted only once per onboarding requisition. A second call is rejected with 409, even if the first payload had a mistake.
• The payload is validated as a whole before anything is stored: when any rule fails, nothing is persisted and you can fix the payload and call again.

PJ onboarding:

• The company object is required.
• The ownership_pct of all partners must sum exactly 100.
• Exactly one partner must have is_legal_representative as true, and that partner's CPF must be the same representative_document sent when the requisition was created. A different CPF is rejected with 400.
• A COMPANY_SOCIAL_CONTRACT document is required.
• When the requisition requires liveness, the person who passed it must be the partner marked as legal representative.

PF onboarding:

• The company object must not be sent.
• partners must contain exactly one person.
• The CPF of that person must be the same document used to create the onboarding requisition.
• When the requisition requires liveness, the person who passed it must be that same person.

Partners:

• Each CPF is validated (mask is stripped and check digits verified) and must be unique within the request.
• A person who already exists on the requisition — the legal representative created from representative_document who completed the liveness — is completed with the data you send, not duplicated.

Documents:

• Every partner declared in partners must have an IMAGE_FRONT document (or an alias that maps to it, such as RG_FRONT, CNH or PASSPORT). The back of the document is optional, since single-face documents such as a digital driver's licence or a passport have no back.
• When the requisition runs without liveness, every partner must also have a SELFIE. Nothing else produces that photo, and the background check compares the face on the selfie with the face on the identification document. A partner without it is rejected with 400 (partner <cpf> is missing SELFIE.) before any file is uploaded. A selfie sent through the form keeps the face comparison but proves no presence, so choosing it over the liveness is a risk decision of whoever configures the onboarding.
• IMAGE_FRONT, IMAGE_BACK and SELFIE must carry a partner_cpf, and that CPF must match one of the partners in the same request. The same applies after an alias is mapped to front or back.
• COMPANY_SOCIAL_CONTRACT and OTHER are attached to the requisition when partner_cpf is null or omitted. If you do send a partner_cpf that matches one of the partners, the file is attached to that person instead; the request is not rejected.
• content must be raw base64, without the data: prefix. Line breaks, spaces and missing = padding inside the value are tolerated and normalised before decoding.

Limits:

• Maximum 8 MB per file, measured after decoding the base64.
• Maximum 25 MB for all files of the request combined, measured after decoding.
• Requests above either limit are rejected with 413 and no file is stored.

Important Notes:

• The response is returned immediately with 202 Accepted; the analysis of the data and documents runs asynchronously.
• 202 Accepted confirms only that the submission was received — it is not an approval decision.
• Keep polling the onboarding status endpoint (GET /v3/onboarding/10482) until current_step is DONE. The final outcome is in status_internal: APPROVED or REJECTED.
• Fields of the company object that you omit keep the value already registered on the requisition; they are not erased.
• The CPF can be sent with or without a mask — 111.444.777-35 and 11144477735 are treated as the same document, in partners and in partner_cpf.