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_partiesare 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

https://partner.sandbox.delos.financial/openapi/v2.html#/operations/BatchService_GetBatchSchema

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	<JWT>	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	"[email protected]"
phone	E.164: + and up to 15 digits, no spaces or brackets	"[phone]"

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_typefrom 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.<section_id>.items.<question_id> 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: "<id>" ──────────────┐
                                     ▼
associated_party_levels["<id>"]
 ├─ fields                            → associated_parties[].fields
 └─ documents                         → associated_parties[].documents

The same level identifiers are listed in party_kyc_levels of the Batch object.

---

Examples

Request

curl --request GET \
  --url <https://partner.sandbox.delos.financial/v2/compliance/batch/01a0af8b-831f-7dbe-8eaf-459f81998958/schema> \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <JWT>'

Response (outline)

{
  "schema_version": "string",
  "individual_schema": {
    "fields": { },
    "documents": [ ],
    "questionnaire": [ ]
  },
  "company_schema": {
    "fields": { },
    "documents": [ ],
    "questionnaire": [ ],
    "associated_parties": [ ]
  },
  "associated_party_levels": {
    "<level_id>": {
      "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:

{ "code": 5, "message": "batch not found", "details": [] }

Authorization fail (401):

{ "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.