Skip to main content
O SDK TypeScript oferece ao código TypeScript e JavaScript executado no servidor acesso tipado à API REST do Dodo Payments. Ele inclui definições de tipos para cada solicitação e resposta, erros tipados, novas tentativas automáticas, timeouts e paginação automática.

Instalação

Instale o pacote dodopayments com seu gerenciador de pacotes:

Início rápido

Crie um cliente e, em seguida, crie uma sessão de checkout:
Se você omitir bearerToken, o cliente lerá a variável de ambiente DODO_PAYMENTS_API_KEY. Se você omitir environment, o cliente se conectará ao modo de produção. Uma chave de API do modo de teste funciona somente com environment: 'test_mode'.
Mantenha as chaves de API em variáveis de ambiente ou em um gerenciador de secrets. Nunca as envie para o controle de versão nem as exponha em código do lado do cliente.

Principais recursos

TypeScript First

Definições de tipos para cada parâmetro de solicitação e campo de resposta, exibidas no seu editor.

Auto-Pagination

Os métodos de listagem buscam a próxima página automaticamente quando você itera com for await...of.

Error Handling

Uma classe de erro tipada para cada status de erro HTTP, com o status, os headers e o corpo da resposta.

Smart Retries

Duas novas tentativas por padrão, com backoff exponencial, para erros de conexão e códigos de status que permitem nova tentativa.

Configuração

Variáveis de ambiente

Armazene sua chave de API em uma variável de ambiente:
.env
O cliente lê estas variáveis quando você não passa a opção correspondente: Se uma URL base estiver definida e você também passar environment, o construtor gerará um erro “Ambiguous URL”. Para usar environment nesse caso, passe baseURL: null. Para verificar um webhook, passe o corpo bruto da solicitação e os headers para client.webhooks.unwrap(rawBody, { headers }). Ele verifica a assinatura com sua chave de webhook e retorna o evento analisado. client.webhooks.unsafeUnwrap(rawBody) analisa o corpo sem verificá-lo; portanto, use-o somente para testes. Consulte Webhooks.

Configuração de timeout

As solicitações atingem o timeout após 1 minuto por padrão. Defina timeout, em milissegundos, no cliente ou em uma única solicitação:
Quando uma solicitação atinge o timeout, o SDK gera APIConnectionTimeoutError. Solicitações que atingem o timeout passam por novas tentativas; portanto, uma chamada pode levar mais tempo do que timeout antes de falhar.

Configuração de novas tentativas

Defina maxRetries no cliente ou em uma única solicitação:
O SDK tenta novamente em caso de erros de conexão e respostas com status 408, 409, 429 ou 500 e superiores. Por padrão, ele tenta novamente duas vezes, com backoff exponencial.
Quando uma solicitação continua falhando, o SDK gera uma subclasse de DodoPayments.APIError. Cada erro possui as propriedades status, headers e error (o corpo da resposta). Verifique uma classe específica com instanceof, por exemplo err instanceof DodoPayments.RateLimitError:

Operações comuns

Os exemplos desta seção usam o client de Início rápido.

Criar uma sessão de checkout

Crie uma sessão de checkout e redirecione o cliente para o checkout_url retornado:
Cada checkout_url funciona uma vez e expira após 24 horas. Para consultar todas as opções de sessão, consulte Checkout Sessions.

Gerenciar clientes

Crie um cliente com endereço de e-mail e nome e, em seguida, recupere-o pelo ID:

Gerenciar assinaturas

Crie uma assinatura, cobre uma assinatura sob demanda e leia o histórico de uso de uma assinatura.
POST /subscriptions (o método subscriptions.create do SDK) está obsoleto. Ele ainda funciona para integrações existentes, mas novas integrações devem criar assinaturas por meio de uma Checkout Session.
billing requer apenas country, um código de país ISO de duas letras. customer recebe { customer_id } para associar um cliente existente ou { email, name? } para criar um. charge é usado para on-demand subscriptions, e product_price está na menor unidade monetária. retrieveUsageHistory retorna uma lista paginada, que você pode percorrer conforme mostrado em Auto-Pagination.

Faturamento baseado em uso

Ingerir eventos de uso

Envie eventos de uso para um cliente:
O event_id é a chave de idempotência; portanto, atribua um valor exclusivo a cada evento. Se o mesmo event_id aparecer duas vezes em uma solicitação, toda a solicitação será rejeitada. Se um event_id já tiver sido ingerido, o novo evento será ignorado. Uma solicitação aceita até 1.000 eventos. timestamp usa o horário atual por padrão e é rejeitado se estiver há mais de 1 hora no passado ou mais de 5 minutos no futuro.

Recuperar eventos de uso

Recupere um único evento pelo seu event_id ou liste eventos filtrados por cliente, nome do evento e intervalo de tempo:
usageEvents.list também aceita meter_id e retorna uma lista paginada.

Configuração de proxy

Para enviar solicitações por meio de um proxy, passe as configurações de proxy do seu runtime em fetchOptions.

Node.js (usando Undici)

Passe um ProxyAgent do undici como dispatcher:

Bun

Defina a opção proxy:

Deno

Crie um cliente HTTP com Deno.createHttpClient e passe-o como client:

Logging

Defina o nível de log com a opção de cliente logLevel ou com a variável de ambiente DODO_PAYMENTS_LOG. A opção do cliente substitui a variável de ambiente.
No nível debug, o SDK registra todas as solicitações e respostas HTTP, incluindo headers e corpos. Alguns headers de autenticação são ocultados, mas dados confidenciais nos corpos ainda podem ficar visíveis.
Os níveis de log, do mais ao menos detalhado, são:
  • 'debug': mensagens de depuração, informações, avisos e erros.
  • 'info': mensagens de informações, avisos e erros.
  • 'warn': avisos e erros. Este é o padrão.
  • 'error': somente erros.
  • 'off': nenhum log.
Por padrão, o SDK registra logs em console. Para usar pino, winston ou outra biblioteca de logging, passe seu logger como opção logger; logLevel ainda controla quais mensagens chegam até ele. As mensagens de log servem apenas para depuração, e seu formato pode mudar entre versões.

Migração do SDK Node.js

Se você usa o SDK Node.js legado, siga o guia de migração para fazer a atualização. O SDK atual usa a API fetch integrada em vez de node-fetch, requer Node.js 20, TypeScript 4.9 e Jest 28 ou posterior e inclui uma ferramenta de migração que atualiza a maior parte do seu código.

View Migration Guide

Saiba como migrar do SDK Node.js para o SDK TypeScript

Paginação automática

Os métodos de listagem retornam resultados paginados. Use for await...of para obter itens de todas as páginas. O SDK solicita a próxima página quando necessário:
Para trabalhar com uma página por vez, leia page.items e chame hasNextPage() e getNextPage():
Para definir o tamanho da página, passe page_size ao método de listagem, por exemplo client.payments.list({ page_size: 50 }).

Requisitos

O SDK é compatível com TypeScript 4.9 ou posterior e com os seguintes runtimes:
  • Navegadores da Web (versões atuais do Chrome, Firefox, Safari, Edge e outros)
  • Node.js 20 LTS ou versões posteriores (non-EOL)
  • Deno 1.28.0 ou posterior
  • Bun 1.0 ou posterior
  • Cloudflare Workers
  • Vercel Edge Runtime
  • Jest 28 ou posterior com o ambiente "node" (o ambiente "jsdom" não é compatível)
  • Nitro 2.6 ou posterior
React Native não é compatível.

Recursos

GitHub Repository

Código-fonte, versões e a lista completa de métodos.

API Reference

Cada endpoint, parâmetro e resposta.

Discord Community

Faça perguntas e converse com outros desenvolvedores.

Report Issues

Relate bugs ou solicite recursos.

Suporte

Para obter ajuda com o SDK TypeScript:

Contribuição

Para contribuir, leia as diretrizes de contribuição.
Última modificação em 26 de setembro de 2026