v2.0 — Nova plataforma CorpX
v2.0 — Nova plataforma CorpX
A v2 é uma reescrita completa da plataforma sobre uma infraestrutura mais rápida e previsível, com integração direta ao novo liquidante. Em geral retrocompatível com a v1.
Tudo o que você precisa para migrar está em um documento só:
- Guia de migração rápida (2 min)
- Referência completa (auditoria endpoint-por-endpoint)
Auth
- Nova base URL:
https://tenant.api.corpx.com/v1(erahttps://api.corpxapi.com/v1) - Novo Token URL:
https://auth.api.corpx.com/oauth2/token - Novos
client_id+client_secretpor integrador (entregues por canal seguro) - Scopes:
api/full→api2/read api2/write Idempotency-Keyvirou opcional (auto-gerado se ausente)X-Tenant-Idé obrigatório em todas as requisições/v1/*(excetoGET /v1/mee health); deve coincidir com o tenant da conta quandoaccountIdestá no path
Statement consolidado em um único endpoint
GET /v1/accounts/{accountId}/statementé agora sempre live — consulta o liquidante em tempo real (sem cache local).- Os endpoints derivados que liam do mesmo cache (
/pix/transactions,/pix/payments,/paymentsalias) também passam a ser live. - A API v1 e o backoffice anteriores continuam no ar em modo somente-leitura por 30 dias após o cutover para consulta histórica.
- Endpoints
/transactions/real-statement,/transactions/legacy-statemente/payments/{id}/legacynão existem na v2 — use/statement(atual) ou a v1 read-only (histórico).
Endpoints deprecated (ainda funcionam até 2026-11-21)
4 paths que existiam na v1 e ficaram fora da versão canônica da v2 voltam como aliases deprecated. Continuam respondendo normalmente, mas anexam 3 headers de aviso na resposta:
Esses headers seguem RFC 8594 (Deprecation) e RFC 9745 (Sunset). Sunset previsto: 2026-11-21 — após essa data passam a retornar 410 Gone. Não aparecem mais no OpenAPI nem na Postman collection.
GET /v1/accounts/{id}/pix/payments/{paymentId}→ use/pix/payments/lookup?identifier=GET /v1/accounts/{id}/payments/{paymentId}(alias sem/pix/) → use/pix/payments/lookup?identifier=GET /v1/accounts/{id}/pix/qr-code(sem/lookup) → use/pix/qr-code/lookup?identifier=POST /v1/accounts/{id}/pix/out/qrcode(sem hífen) → use/pix/out/qr-code
Endpoints removidos (retornam 404 na v2)
GET /v1/accounts/{id}/pix/qr-codes(lista paginada) → consulte um QR por vez com/pix/qr-code/lookup?identifier=, ou use/pix/qr-codes/statspara agregadosPOST /v1/webhooks/replay→ sem substitutoGET /v1/integrator/webhooks→ useGET /v1/webhooksGET /v1/integrator/webhooks/{id}/deliveries→ sem substituto (desde então ganhou um:GET /v1/webhooks/{subscriptionId}/deliveries, com detalhe e retry individual)POST /v1/integrator/events/replay+/batch→ sem substitutoPOST .../pix/med/{medId}/send+/response→ use/decide+/answer
GET /v1/health continua existindo na v2 (ganhou alias adicional
GET /health para health checks externos).
Endpoints novos
GET /v1/me(debug doclient_idautenticado)GET /v1/transactions/{id}/timeline(semaccountIdno path)GET /v1/accounts/{id}/pix/out/bigpix/{batchId}(status agregado de lote BigPix)GET /health(alias do/v1/healthsem o prefixo)- Boleto family (
POST .../boleto/preview|pay,GET .../boleto/payments/{id}) — era 503 na v1, agora ativo
Mudanças de comportamento (mesmo path, novo shape ou semântica)
- Statement e endpoints derivados: cache → live; sem
tariff_refderivado; headerX-Source: live; janela máxima por consulta 31 dias. - Internal transfer
by-bank-account: aceitaholderDocument+holderNameopcionais (não breaking). - Locked balance
unlock: v2 só validalockId; campos extras são ignorados (não breaking). - Campo
feeno objeto de transação removido temporariamente — conciliação manual viaidentifier=fee-{slug}-{operationReferenceId}no extrato. Volta sem mudança de payload em release futura.
MED e webhooks temporariamente suspensos
- Endpoints
/v1/accounts/{id}/pix/med/*retornam HTTP 503 durante a migração. Disputas em aberto seguem o ciclo natural do BACEN — apenas a integração via API está pausada. - Webhooks suspensos:
fee.*,pix.med.*,edi.*. Subscriptions a esses eventos podem permanecer ativas — quando voltarem, retomam automaticamente. Tarifas seguem aparecendo no extrato como linhas independentes (comidentifier=fee-{slug}-{ref}).
Compat (sem mudança no seu código)
- BigPix (
POST .../pix/out/bigpixe.../bank-account/bigpix): body continua single ({amount, key, ...}); chunking permanece server-side, igual à v1. - PIX out variants (
/pix/out/async,/bank-account/async,/bank-account/bigpix): preservados. /v1/accounts/{accountId}/transfers/internal(todos os 3 modos): path e body preservados./v1/accounts/{id}/pix/qr-code/staticbody:valuecontinua como na v1./v1/accounts/{id}/pix/out/qr-code/decode: path preservado./v1/accounts/{id}/pix/keys(GET + POST + DELETE): mantidos./v1/accounts/{id}/pix/key/{pixKey}(DICT lookup): mantido.
Suporte
Contato: api@corpx.com durante o cutover do tenant — resposta em até 1h em horário comercial.
v2.9.0 — Documento da contraparte no extrato
v2.9.0 — Documento da contraparte no extrato
Os itens do extrato (GET /v1/accounts/{accountId}/statement) agora
incluem o documento (CPF/CNPJ) da contraparte além do nome:
recipientName: nome da contraparte (já existente).recipientDocument: novo campo — CPF (11 dígitos) ou CNPJ (14 dígitos) da contraparte, sem máscara (digits-only).counterParty: novo objeto agregando{ name, document }. Omitido quando ambos os campos estão vazios.
Para transações com direction: "IN", a contraparte é o pagador;
para direction: "OUT", é o destinatário. Campos retrocompatíveis —
integradores que não precisam do documento não precisam ajustar nada.