Passer au contenu principal
Les événements sont la base de la facturation basée sur l’utilisation. Envoyez des événements lorsque des actions facturables se produisent, et les compteurs les agrègent en charges.

API Reference - Events Ingestion

Documentation complète de l’API avec exemples et codes de réponse.

Structure de l’événement

event_id
string
requis
Identifiant unique. Utilisez des UUID ou combinez l’ID client + l’horodatage + l’action.
customer_id
string
requis
ID client Dodo Payments. Doit être un client existant valide.
event_name
string
requis
Type d’événement correspondant au nom d’événement de votre compteur (respect de la casse). Exemples : api.call, image.generated
timestamp
string
Horodatage ISO 8601. Par défaut, heure du serveur si omis. Incluez-le pour une facturation précise avec des événements différés/en lots.
metadata
object
Propriétés supplémentaires pour l’agrégation et le filtrage :
  • Valeurs numériques : bytes, tokens, duration_ms
  • Filtres : endpoint, method, quality
metadata: {
  endpoint: "/v1/orders",
  method: "POST",
  tokens: 1024
}

Envoi d’événements

await fetch('https://test.dodopayments.com/events/ingest', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.DODO_PAYMENTS_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    events: [{
      event_id: "api_call_1234",
      customer_id: "cus_abc123",
      event_name: "api.call",
      metadata: { endpoint: "/v1/orders" }
    }]
  })
});
Regroupez jusqu’à 100 événements par requête pour de meilleures performances.

Modèles d’ingestion

Modèles d’événements prêts à l’emploi pour des cas d’utilisation courants. Commencez avec un modèle éprouvé au lieu de construire à partir de zéro.

Meilleures pratiques

Utilisez des identifiants déterministes pour éviter les doublons : ${customerId}_${action}_${timestamp}
Réessayez en cas d’erreurs 5xx avec un backoff exponentiel. Ne réessayez pas les erreurs 4xx.
Omettre pour les événements en temps réel. Inclure pour les événements différés/en lots pour plus de précision.
Suivez les taux de réussite et mettez en file d’attente les événements échoués pour une nouvelle tentative.

Dépannage

  • Le nom de l’événement doit correspondre exactement au compteur (respect de la casse)
  • L’ID client doit exister
  • Vérifiez que les filtres du compteur n’excluent pas les événements
  • Vérifiez que les horodatages sont récents
Vérifiez que la clé API est correcte et utilisez le format : Bearer YOUR_API_KEY
Assurez-vous que tous les champs obligatoires sont présents : event_id, customer_id, event_name
  • Les clés de métadonnées doivent correspondre exactement à la « Propriété sur » du compteur
  • Utilisez des nombres, pas des chaînes : tokens: 150 et non tokens: "150"

Prochaines étapes