Skip to main content
POST
Create IBS repasse operation

Authorizations

Authorization
string
header
required

JWT bearer token issued by the identity provider.

Headers

X-Idempotency
string
required

Idempotency key. Required on every mutation.

X-TTL
string

Idempotency key TTL in seconds.

Body

application/json
amount
string
required

Repasse amount as a decimal string in BRL, minor-unit precision (two decimal places). Canonical form only: exactly two decimal places and no leading integer zeros — the single spelling the durable column stores; anything else is refused at the door with 422.

Pattern: ^(0|[1-9][0-9]*)\.[0-9]{2}$
Example:

"1500.25"

dtRepFinanc
string
required

Financial repasse date in BACEN STR0053 ISO date form (e.g. 2026-06-09). Required and non-blank.

Minimum string length: 1
Example:

"2026-06-09"

identdRepFinanc
string
required

Financial-repasse identifier the comitê gestor keys the repasse on (required, 1-50 characters). This service mints no value for it: an absent or blank identifier is refused with 422.

Required string length: 1 - 50
Example:

"REP-2026-0001"

recipient
object
required

Crediting participant account (comitê gestor) receiving the IBS repasse.

sender
object
required

Debiting participant account originating the IBS repasse.

clientReference
string

Optional caller-supplied correlation reference echoed back for client-side reconciliation.

Example:

"ibs-ref-1"

cnpjOrigdrRepFinanc
string

Optional repasse-originator CNPJ (official CNPJ type: exactly 14 characters, [0-9A-Z]{12}[0-9]{2}). Omitted from the wire when absent.

Pattern: ^[0-9A-Z]{12}[0-9]{2}$
Example:

"12345678000199"

description
string

Optional free-text description carried with the operation.

Example:

"Repasse IBS comite gestor"

infSeggc
object[] | null

Repeating segregation-informe group ([0..n]); each entry requires both an identifier and a timestamp. Absent means the repasse references no informe. No item ceiling is imposed: the official XSD declares maxOccurs='unbounded' and no BACEN rule caps it.

metadata
object

Opaque client-side metadata forwarded verbatim to the legacy submit DTO. NOT persisted on the operation intent or sanitized payload.

qtdTransc
string

Optional transaction count (digits only).

Example:

"10"

Response

Created

acceptedAt
string<date-time>
required

UTC RFC 3339 timestamp at which the command was accepted.

Example:

"2026-05-06T18:30:00Z"

capabilityId
string
required

STR capability identifier resolved for the accepted operation (e.g. STR0004).

Example:

"STR0004"

correlationId
string
required

Request correlation identifier for tracing the accept across logs and traces.

Example:

"req-7c8b3a2e-9f1d-4a55-9b8e-1e1234567890"

isReplay
boolean
required

True when this response replays a prior idempotent accept rather than creating a new operation.

Example:

false

operationFamily
enum<string>
required

Operation family the accepted command belongs to (e.g. bankTransfer).

Available options:
bankTransfer
Example:

"bankTransfer"

operationId
string<uuid>
required

Server-assigned operation aggregate UUID used for subsequent status, return, and cancellation calls.

Example:

"7c8b3a2e-9f1d-4a55-9b8e-1e1234567890"

status
enum<string>
required

Current control-plane lifecycle status of the operation; ACCEPTED on initial accept.

Available options:
ACCEPTED,
SUBMITTED,
SENT,
CONFIRMED,
REJECTED,
FAILED,
PENDING_CONFIGURATION,
PENDING_RECONCILIATION,
RETURN_REQUESTED,
RETURNED,
CANCEL_REQUESTED,
CANCELLED,
RECEIVED,
DELIVERED
Example:

"ACCEPTED"

protocolMetadata
object

Optional SAFE protocol correlation fields; present once the operation is mapped to STR wire identifiers.