Credit API

O contrato cobre mesas, acompanhamento e regras de crédito com autorização por recurso e auditoria de escrita. Veja a visão da extensão.

Functions e Actions

O contrato é o protocolo do módulo: sete operações, e nenhuma rota por recurso. As Functions são as leituras da mesa chamadas por id (credit.watchlists.list, credit.watchlist.board, credit.alerts.list, credit.regulation_terms.queue, credit.notes.list, credit.audit.list, credit.license.get, credit.me.get, entre outras); as Actions são as escritas (credit.note.create, credit.watchlist.create, credit.regulation_term.review…). Cada uma tem catálogo, spec com schemas e execução:

GET  /v1/desk/functions
GET  /v1/desk/functions/{functionId}
POST /v1/desk/functions/{functionId}/execute

GET  /v1/desk/actions
GET  /v1/desk/actions/{actionId}
POST /v1/desk/actions/{actionId}/preview
POST /v1/desk/actions/{actionId}/execute

A execução recebe o sujeito e o input do spec. O sujeito é a mesa (subject.entity_id = id da organização) — nas três leituras endereçadas por lista (credit.watchlist.items, credit.watchlist.board, credit.alerts.list) é o id da watchlist:

curl -X POST https://api.databolsa.com/v1/desk/functions/credit.notes.list/execute \
  -H "authorization: Bearer $DATABOLSA_CREDIT_API_KEY" \
  -H "content-type: application/json" \
  -d '{"subject":{"entity_id":"org_abc123"},"input":{"limit":20}}'

Recusas trazem details.code: subject_required, subject_not_found, invalid_input, scope_missing. Recurso de outra mesa responde 404, nunca 403.

Não há rota REST por recurso: GET /v1/desk/functions e GET /v1/desk/actions são a enumeração do que a mesa faz, e GET /v1/desk/functions/{functionId} traz o input_schema exato de cada leitura. O SDK expõe os mesmos sete métodos.

Perfis do MCP

O contrato declara dois perfis, e desde a poda das rotas os dois recortam o mesmo conjunto: as sete tools do protocolo — catálogo, spec e execução de Functions e Actions —, que alcançam tudo o que a mesa faz.