Acapadev

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çãoclient_credentials (client_id + secret)Personal Access Token
UsoA tua aplicação, em produçãoFerramentas de desenvolvimento e o MCP
Cobranças reaisSimNunca — bloqueadas fora de Test
ÂmbitoA app dona do tokenQualquer 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étodoEndpointDescrição
GET/v1/developer/appsLista as tuas apps. Aceita ?environment=test|live.
GET/v1/developer/apps/resolveResolve uma app por domínio. Parâmetros: url (obrigatório), environment.
POST/v1/developer/appsCria uma app. Aceita environment; por omissão test.
GET/v1/developer/apps/{id}/payment-configO contrato completo de pagamentos da app.
PUT/v1/developer/apps/{id}/payment-configAtualização parcial: billing_webhook_url, subscribe_invoice_paid.

Faturação

MétodoEndpointDescrição
GET/v1/developer/apps/{id}/plansCatálogo de planos.
PUT/v1/developer/apps/{id}/plansSincronização declarativa do catálogo.
POST/v1/developer/apps/{id}/invoicesCria 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}/chargesSó em Test. Gera cobrança simulada.
POST/v1/developer/apps/{id}/invoices/{invoice}/simulateSó em Test. Liquida e dispara invoice.paid.

Webhooks

MétodoEndpointDescriçã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étodoEndpointDescriçã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ódigoSignificado
401PAT inválido, revogado, ou gerado noutro ambiente.
403Operação restrita a ambiente de teste, tentada numa app Live.
404A app ou a fatura não existe, ou não te pertence.
422Validaçã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.

Enter para selecionar ESC para sair