Schemas

The Schema endpoints return country-specific JSON Schema (draft-07) definitions for persons, accounts, and payouts. Query them before building a recipient so your form renders exactly the fields — and the validation rules — that corridor requires.

Because required fields, postal-code formats, document types, and payout methods vary by country, a form hardcoded for one corridor will fail in another. Drive the form off the schema instead:

Build dynamic forms that adapt to each destination country
Validate input client-side using the schema's pattern, enum, minLength, and required
Display the right fields for each payout method (bank deposit, PIX, wallet)

Country code format: the countryCode query parameter is ISO 3166-1 alpha-3 (e.g. BRA, MEX, PHL, USA). Inside the returned schema, the address.countryCode field is alpha-2 (e.g. BR, MX, PH). Don't mix them up.

All responses are draft-07 JSON Schema documents: an object with type, required, and properties, where nested objects (address, payoutMethod) and arrays (documents) carry their own required/properties.

Person Schema

Returns the recipient's identity and address schema for a destination country — the fields you need to build the beneficiary section of the form.

Endpoint

GET https://{FQDN}/schema/person

Headers:

Header	Value
`Authorization`	`Bearer {accessToken}`

Query Parameters

Parameter	Type	Required	Description
`countryCode`	string	Yes	ISO 3166-1 alpha-3 country code (e.g., `"PHL"`, `"BRA"`, `"ESP"`)

Example Request

curl -X GET 'https://{FQDN}/schema/person?countryCode=PHL' \
  -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIs...'

Response (200)

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Inyo Global Recipient Data - Philippines",
  "description": "Schema for a PHL person.",
  "version": "1.0.0",
  "type": "object",
  "required": ["firstName", "lastName", "address"],
  "properties": {
    "firstName": { "type": "string", "description": "The first name of the person.", "minLength": 1 },
    "lastName": { "type": "string", "description": "The last name of the person.", "minLength": 1 },
    "address": {
      "type": "object",
      "description": "The physical address of the person.",
      "required": ["countryCode", "stateCode", "city", "line1", "zipcode"],
      "properties": {
        "countryCode": { "type": "string", "description": "ISO 3166-1 alpha-2 country code.", "enum": ["PH"] },
        "stateCode": { "type": "string", "description": "State or province code.", "enum": ["ABR", "AGN", "ALB", "CEB", "NCR", "..."] },
        "city": { "type": "string", "minLength": 1 },
        "line1": { "type": "string", "minLength": 1 },
        "line2": { "type": "string", "minLength": 1 },
        "zipcode": { "type": "string", "description": "Postal code.", "pattern": "^[0-9]{4}$" }
      }
    }
  }
}

Some corridors add a documents array for national-ID capture (see Per-Country Differences — Brazil requires a CPF):

"documents": {
  "type": "array",
  "minItems": 1,
  "items": {
    "type": "object",
    "required": ["document"],
    "properties": {
      "document": { "type": "string", "description": "CPF (11 digits)", "pattern": "^\\d{11}$" }
    }
  }
}

Account Schema

Returns the recipient's account and payout-method schema for a destination country. The response bundles two things:

asset — the settlement currency for the payout
payoutMethod — a nested object describing how the funds land (bank deposit, PIX, wallet), with the method-specific fields

Note: The payout-method fields are embedded in the account schema as payoutMethod. You do not need to fetch the Payout Schema separately to render the recipient form — it exists for callers who want the payout-method sub-schema on its own.

Endpoint

GET https://{FQDN}/schema/account

Headers:

Header	Value
`Authorization`	`Bearer {accessToken}`

Query Parameters

Parameter	Type	Required	Description
`countryCode`	string	Yes	ISO 3166-1 alpha-3 country code (e.g., `"BRA"`, `"MEX"`, `"USA"`)

Example Request

curl -X GET 'https://{FQDN}/schema/account?countryCode=BRA' \
  -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIs...'

Response (200)

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Inyo Global Account Data - Brazil",
  "version": "1.0.0",
  "type": "object",
  "required": ["asset", "payoutMethod"],
  "properties": {
    "asset": { "type": "string", "description": "Settlement currency (ISO 4217).", "enum": ["BRL"] },
    "payoutMethod": {
      "type": "object",
      "required": ["type", "countryCode", "bankCode", "routingNumber", "accountNumber"],
      "properties": {
        "type": { "type": "string", "description": "Payout method.", "enum": ["BANK_DEPOSIT", "PIX"] },
        "countryCode": { "type": "string", "description": "ISO 3166-1 alpha-2 country code.", "enum": ["BR"] },
        "bankCode": { "type": "string", "description": "Bank code (3 digits).", "pattern": "^\\d{3}$" },
        "routingNumber": { "type": "string", "description": "Branch / agência.", "pattern": "^\\d{1,5}$" },
        "accountNumber": { "type": "string", "pattern": "^\\d{1,13}$" },
        "key": { "type": "string", "description": "PIX key value." },
        "keyType": { "type": "string", "description": "PIX key type.", "enum": ["EMAIL", "PHONE", "DOCUMENT", "EVP"] }
      }
    }
  }
}

The payoutMethod.type enum tells you which fields apply:

`type`	Relevant fields
`BANK_DEPOSIT`	`bankCode`, `routingNumber`, `accountNumber` (varies by corridor)
`PIX`	`keyType`, `key`
`WALLET`	`walletId`, `walletType`, `walletOperator`

Payout Schema

Returns the payout-method sub-schema on its own — the same shape as the payoutMethod object embedded in the Account Schema. Use this when you only need the payout-method fields (e.g. re-validating a payout method without the full account context). For building the recipient form, the account schema already includes everything.

Endpoint

GET https://{FQDN}/schema/payout

Headers:

Header	Value
`Authorization`	`Bearer {accessToken}`

Query Parameters

Parameter	Type	Required	Description
`countryCode`	string	Yes	ISO 3166-1 alpha-3 country code (e.g., `"PHL"`, `"BRA"`, `"MEX"`)

Example Request

curl -X GET 'https://{FQDN}/schema/payout?countryCode=PHL' \
  -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIs...'

Response (200)

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Inyo Global Payout Method - Philippines",
  "version": "1.0.0",
  "type": "object",
  "required": ["type", "countryCode", "accountNumber"],
  "properties": {
    "type": { "type": "string", "description": "Payout method.", "enum": ["BANK_DEPOSIT", "WALLET"] },
    "countryCode": { "type": "string", "description": "ISO 3166-1 alpha-2 country code.", "enum": ["PH"] },
    "bankCode": { "type": "string", "description": "Destination bank code." },
    "accountNumber": { "type": "string", "description": "Bank account number." },
    "walletId": { "type": "string", "description": "Wallet identifier." },
    "walletType": { "type": "string", "description": "Wallet identifier type (e.g. PHONENUMBER)." },
    "walletOperator": { "type": "string", "description": "Wallet operator / provider." }
  }
}

Per-Country Differences

The schemas are the source of truth, but a few corridors have quirks worth calling out. Always render from the live schema rather than hardcoding these — they can change.

Country	Difference
Brazil (`BRA`)	Bank deposit only in some flows — `payoutMethod.type` reduced to `["BANK_DEPOSIT"]`, PIX `key`/`keyType` dropped. Recipient requires a CPF via `documents[].document` (11 digits, numeric, check-digit validated). `bankCode` (3 digits), `routingNumber` = branch/agência.
Mexico (`MEX`)	The CLABE (`accountNumber`) already encodes the bank, so `routingNumber` is not used — it's absent from the schema and the required list. `bankCode` is typically sourced from a bank picker.
Philippines (`PHL`)	`address.stateCode` is an enum of ~70 province codes (`ABR`, `AGN`, … `ZSI`). Full address required; `zipcode` matches `^[0-9]{4}$`.
EU (`AUT`, `BEL`, `FRA`, `IRL`, `ITA`, `PRT`, `ESP`)	`address` is optional — only `firstName` and `lastName` are required. Postal-code `pattern` differs per country (e.g. `^\d{5}$` for ES/FR/IT, `^\d{4}$` for AT/BE, `^\d{4}-\d{3}$` for PT).

How to Consume a Schema

Reading the draft-07 keywords when rendering a field:

Keyword	Use
`type`	Data type: `"string"`, `"object"`, `"array"`, `"number"`, `"boolean"`
`required`	Array of mandatory property names (at that object's level)
`properties`	Field definitions for an object
`items`	Element schema for an array (e.g. `documents`)
`enum`	Allowed values — render a single-value enum as read-only, a multi-value enum as a select
`pattern`	Regex the value must match (postal codes, CPF, account numbers)
`minLength`	Minimum string length
`description`	Human-readable hint — good default for a placeholder or label

Recommended flow:

Read the destination country from step 1 of your form and convert it to ISO-3.
GET /schema/person and GET /schema/account for that ISO-3 code.
Render the recipient form from personSchema.properties and accountSchema.properties (the latter includes payoutMethod).
Validate values against each field's pattern/enum/required.
Submit the collected recipient (identity + address + optional documents) and paymentMethod in the Push Transaction payload.

What's Next

Push Transaction — Build the recipient and paymentMethod from these schemas
Payment Person — Create and validate persons using the schema fields
Banks — Look up bank codes to populate bankCode fields
Check Account — Validate account details before transacting