Das Credit-Modell und die Overage-Abrechnung verstehen

Die CaptainDNS Public API wird in Credits abgerechnet. Ein einfacher DNS-Lookup kostet 1 Credit, ein Deliverability-Score 25. Jeder Plan beinhaltet ein monatliches Credit-Kontingent; Überschreitungen werden am Periodenende abgerechnet (für bezahlte Pläne). Diese Seite erläutert die Details.

Prinzip

Ein Credit ist keine Einheit für Zeit, Daten oder Requests. Es ist eine interne Kosteneinheit, die den Arbeitsaufwand des CaptainDNS-Backends widerspiegelt:

• 1 Credit: ein gecachter DNS-Lookup.
• 2 bis 3 Credits: eine Multi-Resolver-Prüfung oder eine DNSSEC-Kette.
• 5 Credits: ein Multi-RBL-Blacklist-Check oder ein vollständiger SMTP-Test.
• 10 Credits: ein HTTP-Crawl mit Metadaten-Extraktion.
• 30 Credits: ein Deliverability-Score, der SPF, DKIM, DMARC, BIMI und Reputation aggregiert.

Damit lässt sich der Verbrauch einer Integration abschätzen, ohne die exakte Request-Zahl zu kennen: Mittlere Endpunktkosten mal erwartete Anfragen ergibt das ungefähre monatliche Volumen.

Kosten pro Endpunkt

Die folgende Tabelle ist die einzige Quelle der Wahrheit, abgestimmt mit dem OpenAPI-Spezifikation.

Kontingente pro Plan

Jahresabrechnung: 20 % Rabatt (zwei Monate gratis).

Hard Cap: der Free-Plan rechnet keine Overage ab. Sobald die 500 Credits verbraucht sind, liefert jede Anfrage 403 QUOTA_EXCEEDED bis zum Ende der Monatsperiode. Für durchgängigen Betrieb wechseln Sie zu Starter.

Soft Overage: bezahlte Pläne erlauben das Überschreiten des Kontingents. Overage-Credits werden separat geführt und am Monatsende abgerechnet. Die tatsächliche Abrechnung wird erst nach dem Periodenschluss ausgelöst.

Header der API-Antwort

Jede erfolgreiche Antwort enthält drei Accounting-Header:

X-Credits-Limit: 50000
X-Credits-Remaining: 37547
X-Credits-Consumed: 2

• X-Credits-Limit: das monatliche Kontingent des Plans.
• X-Credits-Remaining: noch verfügbare Credits im enthaltenen Kontingent. Wird der Wert negativ, laufen Sie in der Overage (nur bezahlte Pläne).
• X-Credits-Consumed: Credits, die die aktuelle Anfrage verbraucht hat.

Nutzen Sie diese Header zur Steuerung Ihres Clients: protokollieren Sie das Erreichen der 80 %-Marke, bauen Sie Alerts und verlagern Sie nicht-kritische Aufrufe in eine Warteschlange, bevor das Kontingent erschöpft ist.

Verbrauch einsehen

Das Dashboard /account/api-usage zeigt den aktuellen Monat und die vorherigen 12 Monate. Die Admin-API stellt dieselben Daten unter bereit:

{
  "tier": "starter",
  "credits_limit": 50000,
  "credits_used_current": 12453,
  "credits_remaining": 37547,
  "overage_credits_current": 0,
  "overage_eur_cents_per_1k": 100,
  "period_start": "2026-04-01T00:00:00Z",
  "period_end": "2026-05-01T00:00:00Z",
  "history": [
    {
      "period_start": "2026-03-01T00:00:00Z",
      "credits_used": 47821,
      "overage_credits": 0,
      "overage_charged_eur_cents": 0
    }
  ]
}

Überraschungen vermeiden

Vorabschätzung: bevor Sie eine Integration starten, multiplizieren Sie die erwartete Anzahl an Aufrufen mit den durchschnittlichen Kosten. Ein Crawler, der page-crawl-check auf 10.000 URLs pro Monat ausführt, verbraucht 100.000 Credits, also mehr als das Starter-Kontingent.

Backoff in Quotennähe: beobachten Sie X-Credits-Remaining und verlangsamen Sie bei 10 % Restkontingent nicht-dringende Aufrufe.

Deduplikation: bei potenziell redundanten Anfragen nutzen Sie die Idempotenz. Eine Wiederholung innerhalb von 24 Stunden liefert die gespeicherte Antwort, ohne zusätzliche Credits zu verbrauchen.

Getrennte Umgebungen: stecken Sie Ihren cdns_live_*-Schlüssel nicht in einen CI-Job, der 20-mal pro Push läuft. Erstellen Sie einen eigenen cdns_test_*-Schlüssel.

Overage-Abrechnung

Der Paddle-Overage-Worker läuft täglich um 03:00 UTC:

1. Das System identifiziert Perioden, deren Overage nicht gemeldet ist.
2. Für jede Zeile mit overage_credits > 0 berechnet er den EUR-Betrag zum Plan-Tarif.
3. Er ruft POST /subscriptions/{id}/charge auf Paddle mit einer stabilen Idempotency Key (sha256(profile_id|YYYY-MM)) auf, was Doppelabrechnungen bei Retries ausschließt.
4. Er markiert die Zeile als gemeldet mit der Paddle-Charge-ID.

Bei einem Paddle-5xx wird mit exponentiellem Backoff erneut versucht (1s, 5s, 25s). Ein 429 von Paddle löst einen festen 30s-Backoff aus. 4xx-Fehler außer 429 werden nicht automatisch wiederholt.

Nächste Schritte: das Rate Limiting erklärt, wie Sie Ihre Aufrufe glätten, und die Idempotenz, wie Sie Credits bei Retries sparen.