Cadastrar chave PIX de saque
/v1/pix-keysCadastra chave PIX como destino de saque (não é chave de recebimento). O DICT é consultado só aqui: holderName, institutionIspb e holderMatchesMerchant saem dele. Nasce PENDING_VERIFICATION; só vira VERIFIED pela confirmação no portal.
X-Merchant-Id é obrigatório com credencial de organização; com credencial de merchant é opcional (ausente = o próprio merchant).
kodanoOAuth payouts:destinations:writeAuthorizationBearer <token>Token obtido no Zitadel do ambiente (POST /oauth/v2/token), fora do host da API, e enviado em Authorization: Bearer <access_token>.
- Sandbox:
https://kodano-uat-p55zt6.us1.zitadel.cloud/oauth/v2/token - Produção:
https://kodano-prod-qe8hbt.us1.zitadel.cloud/oauth/v2/token
Use sempre o tokenUrl devolvido na emissão da credencial. Duas variantes: private_key_jwt (preferida; grant urn:ietf:params:oauth:grant-type:jwt-bearer com assertion RS256 assinada pela chave da credencial, iss = sub = userId, aud = authority do Zitadel, kid = keyId) e client_secret (grant client_credentials). O OpenAPI só modela a segunda.
O parâmetro scope do token é OIDC, não os escopos da API: openid urn:zitadel:iam:org:project:id:<projectId da API>:aud urn:zitadel:iam:user:resourceowner. Sem o :aud a API responde 401 AUTH.TOKEN_INVALID; sem resourceowner, 403 AUTH.TENANT_MISMATCH.
Os 28 escopos abaixo são os entitlements concedidos à credencial pelos produtos de integração (produto:recurso:ação; write não implica read), avaliados a cada requisição; não são pedidos no token. O tenant vem da organização do token; o merchant, de X-Merchant-Id. Revogar a credencial nega os tokens já emitidos em até 60 s.
Scope: payouts:destinations:write
X-Merchant-Id*stringMerchant da operação (mrc_ + Guid sem hífens, minúsculo). Obrigatório com credencial de organização (ausente → 400 MERCHANT.HEADER_REQUIRED); com credencial de merchant é opcional (ausente = o próprio merchant). Malformado, repetido, inexistente ou de outro tenant → 403 MERCHANT.FORBIDDEN (nunca 404). Vazio = ausente.
^mrc_[0-9a-f]{32}$Idempotency-Key*stringUUID, retido por 24 h a partir da primeira chamada. Escopo: (tenant, merchant, rota-template, chave). Mesma chave e mesmo corpo → resposta original (2xx ou 4xx) com X-Idempotent-Replay: true; corpo ou path concreto diferente → 409 IDEMPOTENCY.CONFLICT; em execução ou desfecho desconhecido → 409 IDEMPOTENCY.IN_PROGRESS com resourceId e Retry-After: 2. Ausente ou não-UUID → 422 IDEMPOTENCY.KEY_REQUIRED.
uuidX-Correlation-Id?stringOpcional, sempre ecoado na resposta e repetido em correlationId do Problem. Ausente ou inválido → o serviço gera UUID v7.
^[A-Za-z0-9._-]{1,64}$application/json- body
type*PixKeyType"CPF""CNPJ""PHONE""EMAIL""EVP"key*stringNormalizado antes da consulta ao DICT.
1 <= lengthChave cadastrada (ou replay).
application/json- response
id*string^pxk_status*string"PENDING_VERIFICATION""VERIFIED"type*PixKeyType"CPF""CNPJ""PHONE""EMAIL""EVP"holderName*stringTitular devolvido pelo DICT.
institutionIspb*stringholderMatchesMerchant*booleancreatedVia*string"API""PORTAL""BACKOFFICE""ONBOARDING"createdAt*stringdate-timeverifiedAt*|date-timecurl -X POST 'https://api.sandbox.kodano.com.br/v1/pix-keys' \ -H 'X-Merchant-Id: mrc_0f8fad5bd9cb469fa16570867728950e' \ -H 'Idempotency-Key: 4b2e8c1a-9d7f-4e3b-a6c5-0f1e2d3c4b5a' \ -H 'X-Correlation-Id: erp-7f3a-0010' \ -H 'Content-Type: application/json' \ -d '{ "type": "EMAIL", "key": "financeiro@acme.com.br"}'{ "id": "pxk_0192f3a2b7c84d1e9f0a1b2c3d4e5f60", "status": "PENDING_VERIFICATION", "type": "EMAIL", "holderName": "ACME LTDA", "institutionIspb": "60701190", "holderMatchesMerchant": true, "createdVia": "API", "createdAt": "2026-10-16T13:02:41Z", "verifiedAt": null}