Skip to main content
Use this reference when building request payloads or interpreting API responses. It brings together shared object shapes and enum values across the 40 documented Open API v3 routes. For required fields, validation, and the fields returned by a particular operation, follow that endpoint’s reference.

Handle JSON correctly

Check numeric enums, decimal-string amounts, timestamps, and optional fields.

Explore shared objects

Find transaction, account, webhook, pagination, and MED object summaries.

Look up enum values

Find the numeric values for payments, accounts, PIX keys, and QR codes.

Check string exceptions

Avoid type mismatches in account documents, webhook events, and fee configuration.

JSON types and field presence

Enums are serialized as native JSON numbers. The service uses Sonic to serialize generated Go structs, rather than protobuf JSON; do not assume protobuf JSON encoding rules apply.
Unknown JSON members are not currently rejected in strict mode. Send only documented fields and do not depend on this acceptance behavior.
A missing or null object does not prove that the field will always be absent. Likewise, a zero or empty value is not enough to infer a business outcome. Interpret it in the context of the endpoint and the relevant status definition.

Example: transaction data

This excerpt from Get Transfer Details illustrates JSON types. It is part of the response data, not a complete response envelope.
Here, txn_status: 2 means COMPLETED, and source_type: 2 means API. Amounts remain strings. The outer response code is a separate API result; see Error Catalog.

Shared objects

These summaries describe shared models, not a guarantee that every listed field is populated in every response. Use the linked endpoint for operation-specific behavior. Party document IDs may be masked according to merchant configuration. Onboarding account references may be absent before the account is activated; see Get Master Account.

Core enums

Use these numeric values for the corresponding fields. The same number can mean different things in different enums: always interpret it with the field name and endpoint context. All values are visible below so you can search this page with ⌘F or Ctrl+F.

Document type

Bank account type

PIX key type

PIX key status

Base status

Transaction status

Source type

Transaction type

Payment method

Payment variant

QR status

QR type

Funds type

Pagination direction

TED purpose

Webhook and onboarding enums

Webhook event selectors and onboarding fields use the following numeric values. For webhook response event names, see string exceptions. Account status and compliance status are separate enums. Read each field independently; the tables list values, not a guaranteed sequence of lifecycle transitions.

Webhook request event type

Managed account model

Compliance status

Master/managed account status

Compliance mode

Login account type

MED enums

Use the canonical numeric fields to interpret MED status and events. Display strings are described under string exceptions. For case details, timelines, and available actions, see Get MED Case. Do not infer cancellation eligibility or deadlines from a status value alone. Use the endpoint response and its documented behavior.

Case status

Infraction task status

Refund task status

Flow type

Original fraud situation

Timeline event

String exceptions

Some fields intentionally use strings even though related fields use numeric enums. Keep their JSON types distinct.

Account document types

Webhook event types

Webhook create requests and create responses use numeric event types. In get, list, and update responses, WebhookInfo.event_type is a string. For example, Create Webhook returns "event_type": 1, while Get Webhook returns "event_type": "PIX_PAYMENT_IN" inside the webhook object. Do not reuse the numeric response model for both shapes.

Fee configuration and MED display fields

Timestamp and duration checklist

  • Read explicit onboarding, webhook, and MED lifecycle timestamps as Unix milliseconds.
  • Keep other integer time fields unchanged unless the endpoint specifies their unit.
  • Treat dynamic QR expires as a duration in seconds, not an epoch timestamp. It defaults to 7200 seconds. See Generate Dynamic QR Code.

Browse API endpoints

Check required fields, validation rules, and response examples for your operation.

Handle API errors

Interpret the outer result code and choose the next troubleshooting step.