Skip to main content
El SDK de TypeScript proporciona acceso tipado a la API REST de Dodo Payments para código TypeScript y JavaScript del lado del servidor. Incluye definiciones de tipos para cada solicitud y respuesta, errores tipados, reintentos automáticos, timeouts y paginación automática.

Instalación

Instala el paquete dodopayments con tu gestor de paquetes:

Inicio rápido

Crea un cliente y, después, crea una sesión de checkout:
Si omites bearerToken, el cliente lee la variable de entorno DODO_PAYMENTS_API_KEY. Si omites environment, el cliente se conecta al modo live. Una clave de API del modo de prueba solo funciona con environment: 'test_mode'.
Guarda las claves de API en variables de entorno o en un gestor de secretos. Nunca las confirmes en el control de versiones ni las expongas en código del lado del cliente.

Funciones principales

TypeScript First

Definiciones de tipos para cada parámetro de solicitud y campo de respuesta, mostradas en tu editor.

Auto-Pagination

Los métodos de lista obtienen la página siguiente automáticamente cuando iteras con for await...of.

Error Handling

Una clase de error tipada para cada estado de error HTTP, con el estado, los encabezados y el cuerpo de la respuesta.

Smart Retries

Dos reintentos de forma predeterminada, con retroceso exponencial, para errores de conexión y códigos de estado reintentables.

Configuración

Variables de entorno

Guarda tu clave de API en una variable de entorno:
.env
El cliente lee estas variables cuando no pasas la opción correspondiente: Si se establece una URL base y además pasas environment, el constructor genera un error de “Ambiguous URL”. Para usar environment en ese caso, pasa baseURL: null. Para verificar un webhook, pasa el cuerpo sin procesar de la solicitud y los encabezados a client.webhooks.unwrap(rawBody, { headers }). Comprueba la firma con tu clave de webhook y devuelve el evento analizado. client.webhooks.unsafeUnwrap(rawBody) analiza el cuerpo sin verificarlo, así que úsalo únicamente para pruebas. Consulta Webhooks.

Configuración del timeout

Las solicitudes agotan el tiempo de espera después de 1 minuto de forma predeterminada. Establece timeout, en milisegundos, en el cliente o en una sola solicitud:
Cuando una solicitud agota el tiempo de espera, el SDK genera APIConnectionTimeoutError. Las solicitudes cuyo tiempo de espera se agotó se reintentan, por lo que una llamada puede tardar más que timeout antes de fallar.

Configuración de reintentos

Establece maxRetries en el cliente o en una sola solicitud:
El SDK reintenta los errores de conexión y las respuestas con estado 408, 409, 429 o 500 y superiores. De forma predeterminada, realiza dos reintentos con retroceso exponencial.
Cuando una solicitud sigue fallando, el SDK genera una subclase de DodoPayments.APIError. Cada error tiene las propiedades status, headers y error (el cuerpo de la respuesta). Comprueba una clase específica con instanceof, por ejemplo err instanceof DodoPayments.RateLimitError:

Operaciones comunes

Los ejemplos de esta sección utilizan client de Inicio rápido.

Crear una sesión de checkout

Crea una sesión de checkout y, después, redirige al cliente a checkout_url devuelto:
Cada checkout_url funciona una vez y caduca después de 24 horas. Consulta Sesiones de checkout para ver todas las opciones de sesión.

Gestionar clientes

Crea un cliente con una dirección de correo electrónico y un nombre y, después, recupéralo por ID:

Gestionar suscripciones

Crea una suscripción, cobra una suscripción on-demand y consulta el historial de uso de una suscripción.
POST /subscriptions (el método subscriptions.create del SDK) está obsoleto. Sigue funcionando para integraciones existentes, pero las nuevas integraciones deben crear suscripciones mediante una sesión de checkout.
billing solo requiere country, un código de país ISO de dos letras. customer acepta { customer_id } para asociar un cliente existente o { email, name? } para crear uno. charge es para suscripciones on-demand, y product_price está expresado en la unidad monetaria más pequeña. retrieveUsageHistory devuelve una lista paginada que puedes iterar como se muestra en Paginación automática.

Facturación basada en el uso

Ingerir eventos de uso

Envía eventos de uso para un cliente:
event_id es la clave de idempotencia, así que asigna un valor único a cada evento. Si el mismo event_id aparece dos veces en una solicitud, se rechaza la solicitud completa. Si ya se había ingerido un event_id, se ignora el evento nuevo. Una solicitud acepta hasta 1.000 eventos. timestamp toma de forma predeterminada la hora actual y se rechaza si es de hace más de 1 hora o si está más de 5 minutos en el futuro.

Recuperar eventos de uso

Recupera un evento individual mediante su event_id o muestra una lista de eventos filtrados por cliente, nombre del evento y rango temporal:
usageEvents.list también acepta meter_id y devuelve una lista paginada.

Configuración del proxy

Para enviar solicitudes a través de un proxy, pasa la configuración del proxy de tu runtime en fetchOptions.

Node.js (usando Undici)

Pasa un ProxyAgent de undici como dispatcher:

Bun

Establece la opción proxy:

Deno

Crea un cliente HTTP con Deno.createHttpClient y pásalo como client:

Registro

Establece el nivel de registro con la opción de cliente logLevel o la variable de entorno DODO_PAYMENTS_LOG. La opción del cliente sustituye a la variable de entorno.
En el nivel debug, el SDK registra cada solicitud y respuesta HTTP, incluidos los encabezados y cuerpos. Algunos encabezados de autenticación se redactan, pero los datos confidenciales de los cuerpos aún pueden quedar visibles.
Los niveles de registro, de mayor a menor verbosidad, son:
  • 'debug': mensajes de depuración, información, advertencias y errores.
  • 'info': mensajes de información, advertencias y errores.
  • 'warn': advertencias y errores. Este es el valor predeterminado.
  • 'error': solo errores.
  • 'off': sin registros.
El SDK registra en console de forma predeterminada. Para usar pino, winston u otra biblioteca de registro, pasa tu logger como opción logger; logLevel sigue controlando qué mensajes recibe. Los mensajes de registro son únicamente para depuración y su formato puede cambiar entre versiones.

Migración desde el SDK de Node.js

Si usas el SDK antiguo de Node.js, sigue la guía de migración para actualizarlo. El SDK actual utiliza la API integrada fetch en lugar de node-fetch, requiere Node.js 20, TypeScript 4.9 y Jest 28 o posteriores, e incluye una herramienta de migración que actualiza la mayor parte de tu código.

View Migration Guide

Aprende a migrar del SDK de Node.js al SDK de TypeScript

Paginación automática

Los métodos de lista devuelven resultados paginados. Itera con for await...of para obtener elementos de todas las páginas. El SDK solicita la página siguiente cuando la necesita:
Para trabajar con una página a la vez, lee page.items y llama a hasNextPage() y getNextPage():
Para establecer el tamaño de página, pasa page_size al método de lista, por ejemplo client.payments.list({ page_size: 50 }).

Requisitos

El SDK admite TypeScript 4.9 o posterior y estos runtimes:
  • Navegadores web (versiones actualizadas de Chrome, Firefox, Safari, Edge y otros)
  • Node.js 20 LTS o versiones posteriores (no EOL)
  • Deno 1.28.0 o posterior
  • Bun 1.0 o posterior
  • Cloudflare Workers
  • Vercel Edge Runtime
  • Jest 28 o posterior con el entorno "node" (el entorno "jsdom" no es compatible)
  • Nitro 2.6 o posterior
React Native no es compatible.

Recursos

GitHub Repository

Código fuente, versiones y la lista completa de métodos.

API Reference

Cada endpoint, parámetro y respuesta.

Discord Community

Haz preguntas y conversa con otros desarrolladores.

Report Issues

Informa de errores o solicita funciones.

Soporte

Para obtener ayuda con el SDK de TypeScript:

Contribuciones

Para contribuir, lee las directrices de contribución.
Última modificación el 26 de septiembre de 2026