Changelog

September 19, 2026

v2.74.0 — Credencial por conta, assinatura de requisição, PIN e travas de saída

  • Nova credencial delegada: uma credencial por conta, assinada. Uma credencial com o escopo credentials.delegate emite credenciais filhas amarradas a uma conta, com escopos que são sempre subconjunto dos dela, publicKeyPem e allowedIps (1 a 20 CIDRs) obrigatórios. A emissão devolve status: "pending" e um activeFrom 18h à frente — até lá a credencial responde 403 credential_not_yet_active. Revogar é imediato, inclusive durante a carência. Ver Autenticação.
  • Credenciais delegadas chamam https://client.api.corpx.com e assinam toda requisição com JWS detached (ES256 ou PS256) sobre MÉTODO\nPATH?QUERY\nTIMESTAMP\nIDEMPOTENCY_KEY\nX-Content-SHA256, mais os headers X-Request-Timestamp (tolerância de 300s), X-Content-SHA256 e X-Request-Signature. No host antigo elas recebem 403 signed_host_required. Guia novo: Assinatura de Requisição.
  • POST /v1/security/signature/verify devolve a string canônica que esperamos, o hash do corpo e o resultado da verificação, para você acertar a assinatura antes da primeira transação. Sempre 200, nunca cria nada.
  • Chaves públicas e allowlist de IP por credencial, em GET|POST .../credentials/{clientId}/public-keys, DELETE .../public-keys/{kid} e GET|PUT .../credentials/{clientId}/ip-allowlist. Cadastrar chave ou adicionar IP espera 18h (pendingUntil); aposentar chave ou remover IP é imediato. Tenant com credencial delegada tem a allowlist de IP calculada a partir das credenciais, e o PUT /v1/security/ip-allowlist manual passa a responder 409 ip_allowlist_derived.
  • Assinatura de webhook por conta. POST /v1/webhooks aceita accountId: a assinatura passa a receber só os eventos daquela conta. O campo não é editável depois e credencial restrita a contas é obrigada a informá-lo (422 account_id_required). Ver Assinatura por conta.
  • Travas de saída configuráveis pelo titular em GET|PUT /v1/accounts/{accountId}/security/locks: cashoutBlocked, cashoutHours e cashoutSourceIps. Apertar vale na hora; afrouxar espera 6 horas (pendingEffectiveAt), campo por campo. DELETE .../locks/pending cancela o afrouxamento e POST .../locks/pending/approve antecipa com PIN. Saída recusada devolve 423 cashout_locked, 403 cashout_outside_hours ou 403 cashout_source_ip_not_allowed.
  • PIN transacional por operador em PUT /v1/accounts/{accountId}/security/pin, DELETE .../security/pin/{document}, POST .../security/pin/verify e GET .../security/pin/status. Quando a credencial exige PIN, as rotas de saída passam a pedir X-Acting-Document e X-Transaction-Pin (428 pin_required). 3 erros travam por 15 minutos (429), 6 travam até redefinir (423). PIN de 6 a 12 dígitos, sem repetição, sequência ou data de nascimento (422 weak_pin).
  • GET /v1/accounts/{accountId}/shared-access lista os tenants que operam a mesma conta bancária, com displayName, status, since e isCurrent. Só metadado público.
  • Nada muda para as integrações existentes. Credenciais atuais continuam em https://tenant.api.corpx.com sem assinar nada; contas sem trava e sem PIN operam como antes; assinatura de webhook sem accountId continua recebendo os eventos de todas as contas.
September 19, 2026

v2.74.1 — Docs: BaaS e Internet banking

  • Duas seções no site. Navbar BaaS (tenant.api.corpx.com) e Internet banking (client.api.corpx.com). A home deixa de cair no Início Rápido do tenant.
  • llms.txt / llms-full.txt roteiam as duas audiências. Não assuma um único base URL. Filtre o OpenAPI por x-audience (baas, ib ou ambos). Cada summary leva o prefixo [BaaS], [IB] ou [BaaS · IB].
  • Contrato da API não muda. Paths, PIN e travas continuam os do 2.74.0.
September 19, 2026

v2.75.0 — Limites locais no padrão MT

  • GET /v1/accounts/{accountId}/limits/available é rota nova. Devolve as quatro janelas da MT (singleTransfer, daytime, nighttime, monthly) com usedBrl/availableBrl para PIX, TED, boleto e transferência interna. GET /v1/accounts/{accountId}/pix/limits não muda: continua só os tetos do liquidante, sem used.
  • TED, boleto e interna passam a ter teto local só quando o staff grava no backoffice. Sem teto, o comportamento é o de hoje (fail-open). Transferência interna continua consultando o MySQL (limites_cliente); se lá houver teto e a operação couber, autoriza sem hold no ledger.
  • Limite por operador em GET|PUT|DELETE /v1/accounts/{accountId}/limits/operators/{document}: o dono fatia o teto da conta (available = min). Apertar vale na hora; afrouxar espera 6h. PIX só reserva localmente quando existe teto de operador — o liquidante continua barrando o teto da conta.
  • Recusa de PIX com Limite restante: R$ X alinha o used da janela atual. Não há sync periódico nem no GET.
September 19, 2026

v2.75.1 — Staff grava teto local de PIX

  • PATCH /v1/backoffice/accounts/{accountId}/limits aceita pixOut no mesmo formato das outras operações. Sem teto local, PIX continua fail-open no ledger; a MT segue barrando o teto da conta.
  • Reserve de PIX avalia min(conta local, operador) quando o teto da conta existe. GET /pix/limits não muda.
  • used passa a ser um contador atômico por janela (account_limit_usage), não SUM dos holds. Vários PIX da mesma conta ao mesmo tempo enfileiram na linha da janela; o teto não fura. Holds ficam só para saga e idempotência.