Changelog

Relevant changes to INFI’s public API.

2026-06-04 — Third-party recipient registration via API

New endpoint POST /v1/recipients to submit third-party recipients (CPF/CNPJ different from the account holder) directly via API — previously, registration was only done through support.

• Registration creates the recipient as pending_review: it does not approve and does not enable withdrawals. Approval (KYC/AML) is still performed by INFI. Only after activation does the recipient appear in GET /v1/recipients and become usable in POST /v1/withdraw via recipientId.
• Idempotent by document: resending the same CPF/CNPJ returns the same recipientId (no duplicates); an already-approved recipient is not downgraded.
• Name-match: a cpf/cnpj key must match the document. Default limit of 10 recipients (active + under review) per account — adjustable per account via support.

See Register recipient.

2026-06-02 — Automatic webhook retry

Webhook deliveries that fail with a transient error (timeout, network error, HTTP 5xx, 429, 408) are now automatically redelivered with backoff: 1min → 5min → 30min → 2h → 6h (up to 6 attempts, ~9h). Before, there was a single automatic attempt — recovery depended on polling or manual resend.

• 4xx is not retried (400/401/403/422…): it means the endpoint refused the event; hammering would not help. Fix the cause and use manual resend.
• eventId is preserved across attempts — dedup by X-Infi-Event-Id is mandatory. The timestamp and X-Infi-Signature are regenerated on each attempt; the eventId is not.
• With this, an event-driven flow is recommended: react to the webhook + maintain your balance from netCents + lightweight reconcile, no aggressive polling of GET /v1/balance.

A change in behavior, not contract: no new fields, no action needed for anyone already dedup’ing by eventId. See Retry and idempotency.

2026-05-27 — Automatic normalization of document.type and pixKeyType + more informative errors

Additive change: requests already sending correct values continue working without adjustment. What changes is how we handle variations and report errors.

Automatic normalization (Postel’s law) in enum fields:

• customer.document.type in POST /v1/pix: accepts "CNPJ", "Cpf", " cnpj " etc. — case and whitespace variations are normalized internally to lowercase. Before, any non-lowercase was silently converted to "cpf" in sanitization, causing the provider to reject numbers with incompatible length and producing a confusing 502 Erro ao comunicar com gateway.
• pixKeyType in POST /v1/withdraw: same normalization — "CPF", "Email", " evp " accepted.

Document length validation: customer.document.number must have 11 digits when type=cpf or 14 digits when type=cnpj (after removing punctuation). Before, numbers with incompatible length were accepted by INFI and rejected by the PSP.

More informative errors — all 400 payload-validation messages now include the value received (truncated) and what is expected:

// Before
{ "error": "Erro ao comunicar com gateway. Tente novamente." }
// status: 502
 
// Now
{ "error": "customer.document.type deve ser 'cpf' ou 'cnpj'. Recebido: 'CNPJ '." }
// status: 400

Recommendation: sending values lowercase without whitespace is the clean default, but the API no longer requires it.

See Create charge, Initiate withdrawal and Errors.

2026-05-09 — Withdrawal to pre-approved third parties via API

POST /v1/withdraw gained support for the optional recipientId field to withdraw to third-party recipients (CPF/CNPJ that is not the account holder).

• Without recipientId (default): the previous behavior — only the registered holder’s CPF/CNPJ, other types rejected.
• With recipientId: enables all 5 PIX key types (cpf, cnpj, email, phone, evp) for a recipient pre-approved by the INFI team (compliance/AML).

recipientId approval is manual — contact support with the recipient’s legal name and CPF/CNPJ. No self-service endpoint.

New endpoint GET /v1/recipients returns the list of active pre-approved recipients for your account with the corresponding recipientId — use them in POST /v1/withdraw. See List recipients.

Current defenses unchanged: API key, IP allowlist, rate limit, anti-burst, daily/monthly caps, balance validation, idempotency via externalRef. Every third-party withdrawal triggers an internal alert at INFI (continuous audit).

See Initiate withdrawal for the full schema, key-type restrictions and examples.

2026-05-09 — PIX data in webhooks and REST queries

New optional fields delivered when the transaction has actually settled on the SPI network. Additive change — clients that do not use them ignore them, no adaptation needed.

• Webhooks transaction.paid, transaction.refunded, transaction.partially_refunded now carry:

  • endToEndId — BACEN-standard E2E ID of the PIX (format E<ISPB><YYYYMMDDhhmm><id>).
  • payer — who paid: { name, document, documentType, bankAccount: { ispb, branch, account } }.

• Webhooks transfer.paid, transfer.refunded, transfer.partially_refunded now carry:

  • endToEndId — E2E ID of the PIX OUT.
  • beneficiary — who received the withdrawal: same structure as payer.
  • refundEndToEndId — only on refunds (transfer.refunded / transfer.partially_refunded): E2E ID of the refund PIX, distinct from the original PIX OUT.

• REST GET /v1/transactions/:id and GET /v1/transactions return the same fields when applicable. Polling becomes an equivalent fallback to the webhook.

Events without settlement (transaction.failed, cancelled, expired, transfer.created, processing, pending_approval, approved, rejected, failed, cancelled) do not carry these fields — they are omitted from the JSON, not returned as null.

LGPD note: payer.* and beneficiary.* contain personal data (name, CPF/CNPJ, bank account). You are the controller for subsequent processing. See Events.

2026-05-08 — Multi-webhook + delivery history

• Multiple webhook URLs per account (up to 6). Each URL filters events by canonical name or by semantic category (cashin, cashout, refund, dispute, chargeback). See Configuring webhook.
• Standardized canonical event catalog: 21 transaction.* and transfer.* events with stable names in X-Infi-Event and in the body’s event field. See Events.
• New events delivered for the first time: transaction.partially_refunded, transaction.infraction, transaction.dispute, transaction.protest, transaction.blocked, transaction.chargeback, transfer.created, transfer.processing, transfer.partially_refunded.
• New header: X-Infi-Event-Id with a unique identifier per event. Same across fanout URLs and manual resends — use it for dedup.
• Delivery history in the dashboard (60-day retention): timeline of each attempt with exact payload, HTTP status and duration. Available in the transaction or in the global list.
• Manual webhook resend: button to fire a new attempt for a historical delivery. eventId is preserved (idempotency); timestamp and signature regenerated. Limit 10/h per account. See Manual redelivery.

Naming breaks (note if you integrated before May/2026)

The following names were replaced by the canonical ones:

If you compared by the old name, update. The status in the body (stable field) remains the same.

2026-05-08 — Dashboard 2FA (no API impact)

• Merchants can now enable two-factor authentication (TOTP) in the dashboard, under Settings → Security.
• No change in the REST API contract. API keys continue to work exactly as before — no extra code, no new header, no change in requests or responses.
• Withdrawals initiated through the dashboard now require a TOTP code at the time of the operation. Withdrawals via POST /v1/withdraw remain unchanged (auth by API key + IP allowlist + rate limit).

2026-05 — Public documentation launch

• Initial version covering:
  • POST /v1/pix — PIX charge creation.
  • POST /v1/withdraw — PIX withdrawal.
  • GET /v1/balance — balance.
  • GET /v1/transactions and GET /v1/transactions/:id — listing and lookup.
  • Single webhook delivered to the endpoint configured by the merchant, HMAC-signed.

[TO BE CONFIRMED WITH THE INFI TEAM]: align the API versioning policy (semver, breaking changes, deprecation timelines) and the final format of this changelog.