Webhook Payloads
Kreditbasierte Abrechnung
Die Nutzlast, die an Ihren Webhook-Endpunkt gesendet wird, wenn ereignisbasierte Änderungen der kreditbasierten Abrechnung eintreten – virtuelle Credits (API-Aufrufe, Tokens, Compute-Stunden) werden gewährt, verbraucht, verfallen, übertragen oder es gibt Guthabenwarnungen. Diese Webhooks beziehen sich nicht auf Customer Wallets (monetäre Guthaben).
Kreditbasierte Abrechnung Webhook-Ereignisse
Die folgenden Webhook-Ereignisse stehen zur Verfügung, um Änderungen im Lebenszyklus der kreditbasierten Abrechnung nachzuverfolgen. Diese Ereignisse gelten für virtuelle Credit-Berechtigungen (API-Aufrufe, Tokens, Compute-Stunden), nicht für Customer Wallets (monetäre Guthaben).| Ereignis | Beschreibung |
|---|---|
credit.added | Gutschriften werden einem Kunden gewährt (über Abonnement, Einmalkauf, Add-on oder API) |
credit.deducted | Gutschriften werden durch Nutzung oder manuelle Belastung verbraucht |
credit.expired | Unbenutzte Gutschriften sind nach der konfigurierten Verfallsfrist verfallen |
credit.rolled_over | Unbenutzte Gutschriften werden am Zyklusende in eine neue Gewährung übertragen |
credit.rollover_forfeited | Gutschriften verfallen, weil die maximale Übertragsanzahl erreicht wurde |
credit.overage_charged | Überlastungsgebühren werden erhoben, wenn die Nutzung über den Nullsaldo hinaus fortgesetzt wird |
credit.overage_reset | Aufgelaufene Überlastungsgebühren werden zurückgesetzt (z. B. zu Beginn eines neuen Abrechnungszeitraums) |
credit.manual_adjustment | Manuelle Gutschrift oder Belastungsanpassung über Dashboard oder API vorgenommen |
credit.balance_low | Guthaben fällt unter die konfigurierte Schwelle für niedrigen Saldo |
Ledger-Ereignisse
Alle Ledger-Ereignisse (credit.added bis credit.manual_adjustment) verwenden dieselbe CreditLedgerEntryResponse-Nutzlast, die im untenstehenden Schema dokumentiert ist.
Die Nutzlast enthält ein metadata Feld, das aus der Quelle des Kreditgewährung aufgelöst wurde — dem bei der Kasse erstellten Abonnement oder der Zahlung. Dies ermöglicht es Ihnen, Wallet-Guthaben von Ihrem eigenen Checkout metadata (zum Beispiel ein orgId) zu verknüpfen, anstatt dem von Dodo ausgegebenen customer_id: Kredite aus Abonnements zeigen das Abonnement’s metadata und Kredite aus Zahlungen zeigen das Zahlung’s metadata. Das Feld ist leer, wenn die Kredite keine auflösbare Quelle haben (zum Beispiel, Kredite, die direkt über die API gewährt wurden).
Niedriges Guthaben Ereignis (credit.balance_low)
Dascredit.balance_low Ereignis verwendet eine andere Nutzlast (CreditBalanceLowPayload), die sich auf Schwellenwert-Warnungen konzentriert:
Der Kunde, dessen Guthaben die Warnung ausgelöst hat.
Das Abonnement, das mit diesem Kreditanspruch verbunden ist.
Der Kreditanspruch, der ein niedriges Guthaben hat.
Anzeigename des Kreditanspruchs.
Aktuelles Guthaben zum Zeitpunkt der Warnung.
Gesamtausgabe von Guthaben pro Abrechnungszyklus für dieses Abonnement.
Der konfigurierte Prozentsatz für den niedrigen Guthabensschwellenwert.
Der absolute Kreditbetrag, dem der Schwellenwert entspricht.
Verwenden von credit.balance_low für proaktive Warnungen
Verwenden Sie das credit.balance_low Webhook, um Kunden zu benachrichtigen, bevor sie ihr Guthaben aufbrauchen:
Get Customer Balance
Überprüfen Sie den aktuellen Kontostand eines Kunden über die API.
Create Ledger Entry
Manuell den Kontostand eines Kunden gutschreiben oder belasten.
Webhook-Payload-Schema
Response for a ledger entry
Brand id this credit ledger entry belongs to
Metadata associated with the credit grant's source (the subscription or payment created at checkout). Empty when the grant has no resolvable source (e.g. credits granted directly via the API).
Verfügbare Optionen:
credit_added, credit_deducted, credit_expired, credit_rolled_over, rollover_forfeited, overage_charged, overage_reset, auto_top_up, manual_adjustment, refund Zuletzt geändert am 26. Juni 2026