v2.74.0 — Per-account credentials, request signing, PIN and cashout locks

  • New delegated credential: one credential per account, signed. A credential holding the credentials.delegate scope issues child credentials bound to one account, with scopes that are always a subset of its own, and both publicKeyPem and allowedIps (1 to 20 CIDRs) required. Issuing returns status: "pending" and an activeFrom 18h in the future — until then the credential answers 403 credential_not_yet_active. Revoking is immediate, including during the grace period. See Authentication.
  • Delegated credentials call https://client.api.corpx.com and sign every request with a detached JWS (ES256 or PS256) over METHOD\nPATH?QUERY\nTIMESTAMP\nIDEMPOTENCY_KEY\nX-Content-SHA256, plus the X-Request-Timestamp (300s tolerance), X-Content-SHA256 and X-Request-Signature headers. On the old host they get 403 signed_host_required. New guide: Request Signing.
  • POST /v1/security/signature/verify returns the canonical string we expect, the body hash and the verification result, so you can get signing right before your first transaction. Always 200, never creates anything.
  • Public keys and IP allowlist per credential, at GET|POST .../credentials/{clientId}/public-keys, DELETE .../public-keys/{kid} and GET|PUT .../credentials/{clientId}/ip-allowlist. Adding a key or adding an IP waits 18h (pendingUntil); retiring a key or removing an IP is immediate. For tenants that have delegated credentials the tenant IP allowlist is derived from those credentials, and the manual PUT /v1/security/ip-allowlist now answers 409 ip_allowlist_derived.
  • Per-account webhook subscriptions. POST /v1/webhooks accepts accountId: the subscription then receives only that account’s events. The field cannot be edited afterwards, and a credential restricted to specific accounts must provide it (422 account_id_required). See Per-account subscriptions.
  • Cashout locks configured by the account holder at GET|PUT /v1/accounts/{accountId}/security/locks: cashoutBlocked, cashoutHours and cashoutSourceIps. Tightening applies immediately; loosening waits 6 hours (pendingEffectiveAt), field by field. DELETE .../locks/pending cancels the scheduled change and POST .../locks/pending/approve brings it forward with the PIN. A blocked cashout returns 423 cashout_locked, 403 cashout_outside_hours or 403 cashout_source_ip_not_allowed.
  • Per-operator transaction PIN at PUT /v1/accounts/{accountId}/security/pin, DELETE .../security/pin/{document}, POST .../security/pin/verify and GET .../security/pin/status. When the credential requires a PIN, cashout routes start requiring X-Acting-Document and X-Transaction-Pin (428 pin_required). 3 wrong attempts lock for 15 minutes (429), 6 lock until reset (423). PIN is 6 to 12 digits, no repetition, sequence or birth date (422 weak_pin).
  • GET /v1/accounts/{accountId}/shared-access lists the tenants operating the same bank account, with displayName, status, since and isCurrent. Public metadata only.
  • Nothing changes for existing integrations. Current credentials keep calling https://tenant.api.corpx.com with no signature; accounts with no lock and no PIN behave as before; webhook subscriptions without accountId keep receiving every account’s events.

v2.74.1 — Docs: BaaS and Internet banking

  • Two sections on the site. Navbar BaaS (tenant.api.corpx.com) and Internet banking (client.api.corpx.com). Home no longer drops you on the tenant Quick Start.
  • llms.txt / llms-full.txt route the two audiences. Do not assume a single base URL. Filter the OpenAPI by x-audience (baas, ib, or both). Each summary carries the prefix [BaaS], [IB] or [BaaS · IB].
  • The API contract does not change. Paths, PIN and locks stay those of 2.74.0.

v2.75.0 — Local limits in the MT shape

  • GET /v1/accounts/{accountId}/limits/available is new. It returns the four MT windows (singleTransfer, daytime, nighttime, monthly) with usedBrl/availableBrl for PIX, TED, boleto and internal transfers. GET /v1/accounts/{accountId}/pix/limits does not change: it is still the partner ceiling list, with no used field.
  • TED, boleto and internal only get a local ceiling after staff writes one. Without a ceiling, behavior matches today (fail-open). Internal transfers still consult MySQL (limites_cliente); if a teto exists there and the payment fits, it authorizes without a ledger hold.
  • Per-operator limits at GET|PUT|DELETE /v1/accounts/{accountId}/limits/operators/{document}: the owner slices the account ceiling (available = min). Tightening is immediate; loosening waits 6 hours. PIX only reserves locally when an operator ceiling exists — the partner still enforces the account PIX ceiling.
  • A PIX refusal with Limite restante: R$ X aligns used for the current window. There is no periodic sync and the GET does not poll the partner.

v2.75.1 — Staff writes a local PIX ceiling

  • PATCH /v1/backoffice/accounts/{accountId}/limits accepts pixOut in the same shape as the other operations. Without a local ceiling, PIX stays fail-open on the ledger; the partner still enforces the account cap.
  • PIX Reserve evaluates min(local account, operator) when an account ceiling exists. GET /pix/limits does not change.
  • used is now an atomic per-window counter (account_limit_usage), not a SUM of holds. Concurrent PIX on the same account queue on the window row and cannot overshoot. Holds remain for the saga and idempotency only.