Agentes IA · Servidor MCP
API Developer de Faturação
Todas as ferramentas do MCP são, por baixo, chamadas a endpoints REST. Esta página documenta-os para quem quiser usá-los diretamente — num script de CI, numa ferramenta própria, ou simplesmente para perceber o que o assistente está a fazer.
Porque existe uma API separada
A API de pagamentos de produção é M2M: exige um
token client_credentials, e portanto o client_secret da app. Uma ferramenta de
desenvolvimento não o tem, e obrigá-la a rodá-lo invalidaria o segredo que a tua aplicação já usa em
produção.
Existe por isso um espelho autenticado pelo Personal Access Token do dono da app. É deliberadamente mais restritivo do que a API M2M: nada aqui gera uma cobrança real.
API M2M /v1/billing/* | API Developer /v1/developer/apps/* | |
|---|---|---|
| Autenticação | client_credentials (client_id + secret) | Personal Access Token |
| Uso | A tua aplicação, em produção | Ferramentas de desenvolvimento e o MCP |
| Cobranças reais | Sim | Nunca — bloqueadas fora de Test |
| Âmbito | A app dona do token | Qualquer app do utilizador autenticado |
Autenticação
curl https://api.acapadev.com/v1/developer/apps \
-H "Authorization: Bearer O_TEU_PAT" \
-H "Accept: application/json"
Endpoints
Descoberta e configuração
| Método | Endpoint | Descrição |
|---|---|---|
GET | /v1/developer/apps | Lista as tuas apps. Aceita ?environment=test|live. |
GET | /v1/developer/apps/resolve | Resolve uma app por domínio. Parâmetros: url (obrigatório), environment. |
POST | /v1/developer/apps | Cria uma app. Aceita environment; por omissão test. |
GET | /v1/developer/apps/{id}/payment-config | O contrato completo de pagamentos da app. |
PUT | /v1/developer/apps/{id}/payment-config | Atualização parcial: billing_webhook_url, subscribe_invoice_paid. |
Faturação
| Método | Endpoint | Descrição |
|---|---|---|
GET | /v1/developer/apps/{id}/plans | Catálogo de planos. |
PUT | /v1/developer/apps/{id}/plans | Sincronização declarativa do catálogo. |
POST | /v1/developer/apps/{id}/invoices | Cria fatura. Em Test marca metadata.sandbox_mode = true. |
GET | /v1/developer/apps/{id}/invoices/{invoice} | Estado da fatura mais consulta ao gateway. |
POST | /v1/developer/apps/{id}/invoices/{invoice}/charges | Só em Test. Gera cobrança simulada. |
POST | /v1/developer/apps/{id}/invoices/{invoice}/simulate | Só em Test. Liquida e dispara invoice.paid. |
Webhooks
| Método | Endpoint | Descrição |
|---|---|---|
POST |
/v1/developer/apps/{id}/webhooks/test-billing |
Envia um invoice.paid de teste e devolve, de forma síncrona, o estado HTTP da resposta do teu endpoint. |
GET |
/v1/developer/apps/{id}/webhook-deliveries |
Histórico de entregas. Parâmetros: event_type, limit (máximo 50, omissão 10). |
POST |
/v1/developer/apps/{id}/webhooks/rotate-secret |
Gera um novo webhook_secret. Invalida o anterior. |
Gestão pós-venda
| Método | Endpoint | Descrição |
|---|---|---|
GET |
/v1/developer/apps/{id}/subscriptions |
Assinaturas com plano e cliente. Parâmetros: status, user_id, plan_reference_code, limit. |
POST |
/v1/developer/apps/{id}/subscriptions/{subscription}/cancel |
Cancela a assinatura. Idempotente. Não devolve dinheiro nem altera faturas pagas. Fica registado em audit_logs. |
GET |
/v1/developer/apps/{id}/metrics/revenue |
Receita do período. Parâmetros: period (today, 7d, 30d, 90d, ytd, all) e currency. |
Não existe endpoint de reembolso. A plataforma não tem, hoje, qualquer
conceito de reembolso — nem estado refunded nas faturas, nem operação
correspondente no gateway. Um endpoint que se limitasse a mudar um estado diria que o
dinheiro foi devolvido quando não foi. Reembolsos são, por agora, um processo manual.
Exemplo: o loop de validação em curl
# 1. Configurar o webhook e subscrever o evento
curl -X PUT https://api.acapadev.com/v1/developer/apps/7/payment-config \
-H "Authorization: Bearer $PAT" \
-H "Content-Type: application/json" \
-d '{"billing_webhook_url":"https://minhaloja.ao/api/webhooks/billing","subscribe_invoice_paid":true}'
# 2. Disparar um invoice.paid de teste e ver como o teu código respondeu
curl -X POST https://api.acapadev.com/v1/developer/apps/7/webhooks/test-billing \
-H "Authorization: Bearer $PAT" \
-H "Content-Type: application/json" \
-d '{"total":5000,"currency":"AOA","app_reference":"order_1234"}'
A resposta traz a entrega registada, com o estado HTTP e o corpo devolvidos pelo teu endpoint:
{
"status": "success",
"data": {
"target_url": "https://minhaloja.ao/api/webhooks/billing",
"signature_header": "X-AcapaDev-Signature",
"signature_algorithm": "hash_hmac('sha256', json_encode($payload), $webhook_secret)",
"payload_sent": { "...": "..." },
"delivery": { "status": "success", "response_status": 200, "response_body": "" }
}
}
Códigos de erro
| Código | Significado |
|---|---|
401 | PAT inválido, revogado, ou gerado noutro ambiente. |
403 | Operação restrita a ambiente de teste, tentada numa app Live. |
404 | A app ou a fatura não existe, ou não te pertence. |
422 | Validação falhou, ou falta configuração (webhook ou segredo por definir). |
Esta API não substitui a M2M. Em produção, a tua aplicação continua a usar
/v1/billing/* com as suas próprias credenciais — ver
API de Pagamento Direta.