Documentação da API

Erro vem no corpo, como {"error": "..."}. Cliente que decide sucesso por response.ok vai tratar “saldo insuficiente” como pedido criado — e só descobre pelo que não foi entregue.

Se a chamada der timeout, não repita automaticamente. Consulte antes se o pedido existe. Retry cego numa chamada que gasta dinheiro cobra duas vezes pela mesma venda.

multiStatus aceita até 1.000 ids por chamada. E pedido terminal (Completed, Partial, Canceled) não muda mais: pare de consultá-lo, ou o seu job cresce para sempre.

"14.9000", quatro casas, em BRL. Converter para float e somar é como centavo some do seu fechamento. Use decimal.

Escreva um cliente para a API SMM da CurtiPay no meu projeto.

ENDPOINT
POST https://curtipay.com/api/reseller
Corpo em JSON (Content-Type: application/json). Todas as chamadas levam o
campo "key" com a chave de API.

REGRAS QUE NÃO PODEM SER IGNORADAS
1. A API responde SEMPRE com HTTP 200, inclusive em erro. Nunca use o
   código de status para decidir sucesso. Considere erro quando o corpo
   da resposta for um objeto contendo a chave "error", e propague essa
   mensagem.
2. "action": "add" DEBITA saldo no momento da chamada. Trate como
   operação não idempotente: nunca faça retry automático de "add" depois
   de timeout sem antes conferir se o pedido foi criado.
3. Para acompanhar pedidos use "action": "multiStatus" com "orders"
   contendo até 1000 ids separados por vírgula. Não faça uma chamada por
   pedido.
4. Valores monetários vêm como STRING com 4 casas decimais e moeda BRL.
   Não converta para float em cálculo de dinheiro; use decimal.
5. O limite é de 120 chamadas de "add" por minuto por conta. Ao receber
   {"error": "Rate limit exceeded"}, faça backoff exponencial.

ACTIONS
- balance  -> {"balance": "250.0000", "currency": "BRL"}
- services -> lista de serviços; "rate" é o preço por MIL
- add      -> exige service, link e quantity (quantity é dispensada em
              serviço de comentário, que usa "comments" com uma frase por
              linha). Responde {"order": 84213}
- status   -> um pedido, por "order"
- multiStatus -> vários, por "orders"
- cancel   -> até 100 ids em "orders"

STATUS possíveis: Pending, In progress, Partial, Completed, Canceled.

O QUE EU QUERO
Um módulo com funções tipadas para cada action, tratamento de erro
centralizado (uma exceção própria com a mensagem da API), retry com
backoff apenas nas chamadas de leitura, e testes cobrindo: erro com HTTP
200, rate limit, e multiStatus com id inexistente no meio do lote.

Integre a API SMM da CurtiPay ao meu sistema de pedidos.

Contexto: quando um cliente meu compra um serviço, eu preciso criar o
pedido na CurtiPay, guardar o id retornado e depois acompanhar o status
até concluir.

ENDPOINT: POST https://curtipay.com/api/reseller (JSON, campo "key" com a chave de API)

FAÇA ASSIM
1. Ao confirmar o pagamento do meu cliente, chame "add" com service, link
   e quantity. Guarde o "order" retornado na MINHA tabela de pedidos,
   numa coluna própria (ex.: fornecedor_pedido_id). Sem isso eu perco o
   vínculo e não consigo mais consultar nada.
2. Crie um job periódico (a cada 5 minutos) que pegue TODOS os meus
   pedidos ainda não terminais, monte lotes de até 1000 ids e chame
   "multiStatus" uma vez por lote. Atualize o status de cada um.
3. Pedido com status Completed, Partial ou Canceled é TERMINAL: pare de
   consultar. Continuar consultando pedido terminal é o que faz o job
   crescer para sempre.
4. Trate erro pelo corpo, nunca pelo HTTP — a API responde 200 mesmo em
   erro, com {"error": "..."} .
5. Registre em log toda chamada de "add" com o corpo enviado e a resposta
   recebida. É a única forma de auditar uma cobrança depois.

ATENÇÃO AO DINHEIRO
"add" debita no ato. Se a chamada der timeout, NÃO repita
automaticamente: consulte antes se o pedido existe, ou você paga duas
vezes pela mesma venda.

Escreva um sincronizador de catálogo da API SMM da CurtiPay.

POST https://curtipay.com/api/reseller com {"key": "...", "action": "services"}

A resposta é uma lista de serviços com: service (id), name, type,
category, rate (preço por MIL, string com 4 casas), min, max, refill,
cancel, currency.

O QUE EU PRECISO
1. Um comando que busque a lista e faça upsert na minha tabela de
   serviços, casando pelo campo "service" (id do fornecedor), NUNCA pelo
   nome — nome muda.
2. Marcar como inativo, em vez de apagar, o serviço que sumiu da lista:
   pode haver pedido meu apontando para ele.
3. Aplicar a MINHA margem em cima do "rate" para gerar o meu preço de
   venda, com a margem configurável por serviço e um padrão global.
4. Respeitar min e max ao validar o pedido do meu cliente ANTES de mandar
   para a API — assim o erro aparece na minha tela, e não como um débito
   recusado depois.
5. Rodar isso uma vez por dia e registrar o que mudou de preço, para eu
   revisar se alguma margem ficou negativa.