> For the complete documentation index, see [llms.txt](https://docs.delos.financial/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.delos.financial/batchservice/get-batch-schema.md). # Get Batch Schema Returns the **frozen schema snapshot** of a batch: the verification requirements captured when the batch was created. Every manifest row is validated against this snapshot, even if the requirements change later, so this is the reference for building `manifest.json`. The schema is available in every batch status. A manifest row mirrors the schema: `fields`, `documents`, `questionnaire` and, for company rows, `associated_parties`are filled in against the part of the schema with the same name. You rarely need to build a manifest from the schema by hand. Get Example Manifest returns a template generated from this snapshot. Use the schema to check requirements, allowed values and conditional questions. **Endpoint** `GET /v2/compliance/batch/{batch_id}/schema` **Link** **Request** **Path Parameters** | Parameter | Type | Description | Required | Example | | -------------- | -------- | ---------------------------------- | -------- | ---------------------------------------- | | **`batch_id`** | `string` | Batch ID returned by Create Batch. | Yes | `"01a0af8b-831f-7dbe-8eaf-459f81998958"` | **Headers** | Key | Value | Required | | --------------- | ------------------ | -------- | | `Authorization` | `` | Yes | | `Accept` | `application/json` | Yes | **Response (200 OK)** Returns a `GetBatchSchemaResponse`. **Response Fields** | Field | Type | Description | | ----------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **`schema_version`** | `string` | Version of the snapshot. Same value as `schema_version` of the batch; you can pass it in `manifest.json`. | | **`individual_schema`** | `object` | Requirements for `individual` rows: `fields`, `documents`, `questionnaire`. Absent if the batch does not accept individuals. | | **`company_schema`** | `object` | Requirements for `company` rows: `fields`, `documents`, `questionnaire`, `associated_parties`. Absent if the batch does not accept companies. | | **`associated_party_levels`** | `object` | Requirements for company participants (UBOs, directors, authorized signatories), keyed by opaque level identifiers. Each entry has its own `fields` and `documents`. | *** **Schema structure** Each subject schema (`individual_schema`, `company_schema`, and every entry of `associated_party_levels`) is built from the parts below. **`fields` — profile fields** Describes every profile field the row can carry. For each field the schema states: * whether it is **required** — required fields must have a non-empty value; * the **value type** — the value in the manifest must have this type; * the **format**, if any — the value must match it: | Format | Rule | Example | | ------- | ----------------------------------------------------- | -------------------- | | date | `YYYY-MM-DD` | `"1990-05-14"` | | country | ISO 3166-1 alpha-2 code | `"CY"` | | email | Valid address with `@` and a domain | `"anna@example.com"` | | phone | E.164: `+` and up to 15 digits, no spaces or brackets | `"+35799000000"` | In the manifest: `fields` is an object keyed by field id, e.g. `{"firstName": "Anna"}`. **`documents` — document groups** Describes which documents the row must or may provide, organized in groups (for example, identity document and proof of address). For each group the schema states: * whether the group is **required** — every required group must be covered by at least one document; * the **allowed document types** in the group; * which of those types are **two-sided** (`two_sided_types`) — such documents are sent as two entries with `sub_typeFRONT_SIDE` and `BACK_SIDE`. For companies, company documents use the type `COMPANY_DOC`; the specific kind of document is selected with `sub_type`from the list the group allows. In the manifest: `documents` is an array of `{"type", "sub_type", "file"}` entries. **`questionnaire` — questionnaire** A blank questionnaire form: sections, and questions inside each section. For each question the schema states its **id**, **type**, **options** (for choice questions) and whether it is **required**. Some questions are shown only depending on the answer to another question. If the level has no questionnaire, `questionnaire` is an empty array. In the manifest: `questionnaire.sections..items.` holds the answer, whose shape depends on the question type: | Question type | Answer shape | | --------------- | ---------------------------------------------------- | | Regular | `{"value": "..."}` | | Multiple choice | `{"values": ["...", "..."]}` (each one of `options`) | | File attachment | `{"files": ["path/in/prefix.pdf"]}` | **`associated_parties` — company participants (`company_schema` only)** Lists the participant roles a company must or may declare. For each role the schema states: * the **role** — `UBO`, `DIRECTOR` or `AUTHORIZED_SIGNATORY`; * **`can_skip`** — if `false`, at least one party with this role is mandatory; * the **applicant type** of the party; * the **level** — an opaque reference to the entry in `associated_party_levels` that holds the party's own `fields` and `documents`. In the manifest: `associated_parties` is an array of parties, each with its own `party_key`, roles in `types`, `fields`, `documents` and, for UBOs, `share_size`. **How the parts connect** ``` company_schema ├─ fields, documents, questionnaire → company row └─ associated_parties[] ├─ role: UBO, can_skip: false └─ level: "" ──────────────┐ ▼ associated_party_levels[""] ├─ fields → associated_parties[].fields └─ documents → associated_parties[].documents ``` The same level identifiers are listed in `party_kyc_levels` of the Batch object. *** **Examples** **Request** ```bash curl --request GET \ --url \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' ``` **Response (outline)** ```json { "schema_version": "string", "individual_schema": { "fields": { }, "documents": [ ], "questionnaire": [ ] }, "company_schema": { "fields": { }, "documents": [ ], "questionnaire": [ ], "associated_parties": [ ] }, "associated_party_levels": { "": { "fields": { }, "documents": [ ] } } } ``` *** **Error Responses** Errors are returned as `{"code", "message", "details"}`, where `code` is a gRPC status code. Use the HTTP status for error handling. **Batch Not Found (404)** — the batch does not exist or belongs to another partner: ```json { "code": 5, "message": "batch not found", "details": [] } ``` **Authorization fail (401)**: ```json { "code": 16, "message": "Unauthorized", "details": [] } ``` *** **Notes** * **Frozen for the batch's lifetime**: the snapshot never changes. To onboard against newer requirements, create a new batch. * **Opaque identifiers**: keys of `associated_party_levels` and the `level` references are identifiers only. Do not parse them or rely on their format. * **Validation is strict**: rows are checked against the snapshot before customers are created — required fields, value types, formats, allowed document types, required document groups, document sides, questionnaire answers and mandatory roles. A row that fails any check becomes `invalid` with the reason in `error`. * **Conditional questions**: the example manifest includes only unconditional questions. If an answer makes another question visible, answer that question too when it is required. * **Markup is not allowed**: values containing `<` or `>` are rejected in profile fields, free-text answers and `external_customer_id`. **Typical Workflow**: 1. Create a batch with Create Batch. 2. Call `GET /v2/compliance/batch/{batch_id}/schema` and check the requirements for each type. 3. Download the template with Get Example Manifest and fill it in against the schema. 4. Upload documents and `manifest.json`, then Commit Batch. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.delos.financial/batchservice/get-batch-schema.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.