Captcha-API-Schlüssel für Ihre Kunden bereitstellen

Wenn Sie CapSkip für andere betreiben, können Sie Captcha-API-Schlüssel in dem Moment bereitstellen, in dem ein Kunde bezahlt, direkt aus Ihrem Billing-Webhook heraus. Remote Key Management stellt POST-Endpunkte bereit, die Schlüssel auf der laufenden Instanz anlegen, auflisten, löschen, begrenzen und abrechnen, und ein neuer Schlüssel gilt schon bei der nächsten Anfrage zum Captcha-Lösen. Kein Neustart, kein manueller Schritt, und zwischen einer bestätigten Zahlung und einem Kunden, der loslegen kann, steht nichts mehr. Jeder Schlüssel kann zusätzlich sein eigenes Guthabenlimit je Captcha-Typ tragen, sodass aus einer Tarifstufe eine Zahl wird, die der Löser selbst durchsetzt, statt einer Regel, die Ihr Billing überwachen müsste. Dieser Beitrag zeigt, wie Sie beim Abschluss einen Schlüssel anlegen, diese Limits setzen und aufstocken, den Verbrauch je Kunde messen, bei der Kündigung entziehen, und welchen Netzwerkfehler dieses Setup besonders leicht macht.

Was Sie brauchen

• CapSkip läuft auf einem Windows-Rechner, über den Sie verfügen. Dieser Rechner ist Ihr Lösungsdienst und der einzige, auf dem die Anwendung überhaupt installiert sein muss. Ihre Kunden installieren gar nichts.
• Der Server-Modus, damit diese Kunden die Instanz auch wirklich erreichen. Der Local-Modus lauscht auf der Loopback-Adresse und bedient nur dieses eine Gerät, während der Server-Modus auf Ihrer Netzwerk- oder öffentlichen IP lauscht, sodass andere Rechner eine Verbindung aufbauen können. Beide Modi sind beschrieben unter Verbindungseinstellungen, und eine statische öffentliche IP sollten Sie haben, bevor Sie die Adresse herausgeben.
• Ein einziger Besuch im CapSkip-Fenster, um den Admin-token zu erzeugen. Das ist der einzige Schritt, der in der Oberfläche stattfindet, und Sie wiederholen ihn nie.
• Ein Ort, von dem aus Sie die Aufrufe absetzen: Ihr Billing-Webhook-Handler, das Backend Ihres Dashboards oder ein Terminal, solange Sie testen.

Eines gehört vor dem Code klar gesagt, weil genau daran dieses Modell hängt. Die Schlüssel, die Sie ausgeben, prägen Sie selbst. Es sind keine bei einem Anbieter gekauften Guthaben, die Sie weiterverkaufen, und einen Schlüssel zu prägen kostet Sie nichts. CapSkip läuft auf Ihrer Hardware, hundert Kundenschlüssel kosten also genau so viel wie einer.

Was ein Schlüssel jetzt tragen kann, ist sein eigenes Guthabenlimit, und zwar getrennt je Captcha-Typ. Damit wird aus einem bloßen Etikett eine Tarifstufe, die der Löser selbst durchsetzt: „Starter, 10.000 reCAPTCHA-Lösungen“ wird zu einer Zahl, die CapSkip herunterzählt, statt zu etwas, das Sie im Auge behalten müssen. Es gibt acht Abrechnungstöpfe, und sie sind bewusst gröber geschnitten als die Aufgabentypen des Lösers:

• Der Topf ImageToText deckt Bild- und OCR-Lösungen ab.
• Der Topf Recaptcha fasst v2, v3 und beide Enterprise-Varianten zusammen.
• Der Topf Turnstile deckt Cloudflare Turnstile ab.
• Der Topf GeeTest deckt GeeTest ab.
• Der Topf Altcha deckt ALTCHA ab.
• Der Topf CaptchaFox deckt CaptchaFox ab.
• Der Topf Capy deckt Capy Puzzle ab.
• Der Topf FriendlyCaptcha deckt Friendly Captcha ab.

Ein Topf ohne gesetztes Limit ist unbegrenzt, und genau so verhielt sich jeder Schlüssel, bevor es diese Funktion gab. Ein Update von CapSkip ändert daher von sich aus nichts: Jeder bereits ausgegebene Schlüssel bleibt in allen acht Töpfen unbegrenzt, bis Sie ein Limit setzen, und ein Anlege-Aufruf, der nichts über Limits sagt, erzeugt weiterhin einen unbegrenzten Schlüssel.

Schritt 1: Remote Key Management einschalten

Der Schalter sitzt in Settings, unter API access, dann Remote Key Management. Schalten Sie ihn ein und drücken Sie die Schaltfläche Generate.

Der token wird genau einmal angezeigt und nur als gesalzener Hash gespeichert, später lässt er sich also nirgends mehr auslesen. Ist er weg, erzeugen Sie einen neuen, und der alte verliert sofort seine Gültigkeit. Um die Admin-API abzuschalten, ohne einen neuen token auszustellen, drücken Sie Revoke, womit der gespeicherte token gelöscht wird. Legen Sie ihn dorthin, wo Ihr Billing seine übrigen Geheimnisse hält, und nicht in Ihren Anwendungscode.

Die Endpunkte liegen auf demselben Host und Port, der Ihre Anfragen zum Lösen ohnehin schon beantwortet. Sprechen Ihre Kunden Port 8080 an, dann liegt dort auch die Admin-API. Das ist bequem, und genau damit müssen Sie vorsichtig sein: dazu weiter unten ein eigener Abschnitt.

Solange die Funktion aus ist, liefert jeder Admin-Pfad einen nackten 404 ohne Body. Genau dieselbe Antwort bekommt ein unbekannter Pfad, und das ist Absicht: Wer den Port abklopft, kann eine Instanz mit abgeschalteter Funktion nicht von einer unterscheiden, die diese Funktion gar nicht kennt.

Schritt 2: einen Schlüssel anlegen, sobald ein Kunde abschließt

Jeder Endpunkt ist POST, nimmt einen JSON-Body entgegen und verlangt einen Authorization-Header, der den token als Bearer-Credential trägt. Der Anlege-Aufruf braucht einen Namen. Übergeben Sie nur den Namen und lassen Sie CapSkip den Wert erzeugen, was hier genau richtig ist: Der Kunde soll sich sein Credential nicht selbst aussuchen. Hängen Sie ein grants-Objekt an, und der Schlüssel kommt bereits mit den Tariflimits dieses Kunden zur Welt.

# No install needed. Name the key after the customer, not after the plan.
curl -X POST http://YOUR_SERVER:8080/admin/keys/add \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"cust_10482","grants":{"Recaptcha":10000,"ImageToText":50000}}'

{
  "errorId": 0,
  "key": {
    "name": "cust_10482",
    "key": "a1b2c3d4e5f6...",
    "grants": {
      "ImageToText": 50000,
      "Recaptcha": 10000,
      "Turnstile": null,
      "GeeTest": null, "Altcha": null, "CaptchaFox": null, "Capy": null, "FriendlyCaptcha": null
    }
  }
}

Die Antwort meldet alle acht Töpfe zurück, nicht nur die beiden, die Sie gesetzt haben, ein nachgelagertes Lesen zur Bestätigung brauchen Sie also nie. Benennen Sie den Schlüssel nach etwas Stabilem aus Ihrem eigenen System, etwa der Kunden- oder der Abonnement-ID. Namen sind eindeutig, und die Regel wird beim Anlegen durchgesetzt, der Name wird damit zum verlässlichen Griff für jede spätere Operation. Schlüssel stattdessen nach Tarif oder Datum zu benennen ist der Fehler, der den Kündigungstag schmerzhaft macht.

Für das grants-Objekt gelten vier Regeln, und die letzte ist die, die Sie rettet:

• Lassen Sie es ganz weg, und der Schlüssel ist überall unbegrenzt. Das ist das bisherige Verhalten, Integrationen aus der Zeit vor den Kontingenten laufen also unverändert weiter.
• Lassen Sie einen Topf weg oder schicken Sie ihn als JSON null, dann ist er unbegrenzt. Schicken Sie stattdessen die Zahl 0, startet er bereits erschöpft.
• Topfnamen sind nicht case-sensitiv, credits muss aber eine schlichte JSON-Ganzzahl ab null sein, niemals eine Zeichenkette in Anführungszeichen und niemals eine Dezimalzahl.
• Zuerst wird die gesamte Anfrage geprüft, und erst danach wird der Schlüssel angelegt. Ein unbekannter Topfname oder eine schlechte Zahl liefern einen 400 und legen nichts an, eine abgelehnte Anfrage kann also niemals einen halb begrenzten Schlüssel hinterlassen.

Setzen Sie die Limits bei der Erstellung, statt den Schlüssel anzulegen und ihn hinterher einzuschränken. Der zweite Weg lässt ein Fenster offen, so kurz es auch sei, in dem ein brandneuer Kundenschlüssel völlig ohne Limits live ist.

Diese Eindeutigkeitsregel ist zugleich Ihr Schutz gegen Doppelverarbeitung. Zahlungsanbieter senden Webhooks erneut, und ein wiederholtes Abschluss-Ereignis kommt als 409 mit ERROR_KEY_EXISTS zurück, statt still einen zweiten Schlüssel für denselben Kunden anzulegen. Behandeln Sie diesen 409 in Ihrem Handler als Erfolg, dann ist das Wiederholungsproblem erledigt.

Der Wert kommt genau einmal zurück, in eben dieser Antwort. Zeigen Sie ihn dem Kunden oder speichern Sie ihn dort, wo Ihr Dashboard liest, denn das spätere Auflisten der Schlüssel ist eine Admin-Operation und nichts, was Sie ausführen wollen, um ein einzelnes Credential wiederzubeschaffen.

Schritt 3: Limits bei Upgrade oder Verlängerung anpassen

Der grant-Endpunkt schreibt das Limit eines Topfes auf einen Schlüssel. Den Schlüssel wählen Sie über den Namen oder über den Wert, genau eines von beiden, ganz so wie beim Löschen.

# Upgrade: replace the limit outright.
curl -X POST http://YOUR_SERVER:8080/admin/keys/grant \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"cust_10482","bucket":"Recaptcha","credits":25000,"mode":"set"}'

# Top-up: add to whatever is left.
#   -d '{"name":"cust_10482","bucket":"Recaptcha","credits":10000,"mode":"add"}'

Die beiden Modi sind nicht symmetrisch. Der set-Modus ersetzt die Zahl vollständig, und ein credits-Wert von JSON null oder ein weggelassenes Feld setzt das Limit im set-Modus zurück auf unbegrenzt. Das ist der einzige Weg, ein einmal gesetztes Limit wieder loszuwerden. Beachten Sie, dass ein credits-Wert von 0 das Gegenteil bedeutet: Er erschöpft den Topf, statt die Begrenzung aufzuheben. Der add-Modus rechnet den vorhandenen Wert plus Ihre Zahl und behandelt unbegrenzt als 0, er richtet also auf einem Topf ohne Limit erst eines ein. Er verlangt einen credits-Wert über 0.

Drei Anfrageformen werden abgelehnt statt ausgeführt, jede deshalb, weil der Fehlschlag sonst unsichtbar bliebe:

• Null addieren. Ein nächtliches Aufstock-Skript, das Ziel minus Ist rechnet, liefert für jeden Kunden, der bereits am Ziel ist, genau 0. Gegen einen unbegrenzten Topf würde das ein Limit von exakt 0 einrichten und diesen Schlüssel vom Lösen abhalten. Nehmen Sie den set-Modus, wenn Sie 0 meinen.
• Negative Zahlen, in beiden Modi. Minus 500 zu addieren liest sich auf einem begrenzten Topf wie ein Abzug, dieselbe Anfrage gegen einen unbegrenzten Topf fällt jedoch auf 0 und macht ihn still zu einem erschöpften. Die aufrufende Seite kann aus der eigenen Anfrage nicht ableiten, was sie bekommt, also ist beides untersagt.
• Zahlen in Anführungszeichen. Den credits-Wert als Zeichenkette zu schicken meint „begrenze diesen Schlüssel auf diese Zahl“, als fehlender Wert gelesen bedeutet es jedoch das genaue Gegenteil, nämlich das Limit aufzuheben, und meldet trotzdem Erfolg. Zahlen zu quoten ist genau das, was ein Shell-Skript versehentlich tut, schicken Sie credits also ohne Anführungszeichen.

Eines sollten Sie einplanen: Ein Grant ist ein Guthabenstand, kein Monatskontingent. In CapSkip läuft nichts nach Kalender. Rufen Sie für einen verbrauchsabhängigen Monatstarif den grant-Endpunkt im set-Modus mit dem Tarifkontingent zu Beginn jedes Abrechnungszeitraums auf, aus Ihrem Verlängerungs-Webhook. Für einen Tarif, bei dem ungenutztes Guthaben übertragen wird, nehmen Sie stattdessen den add-Modus mit dem Kontingent des Zeitraums.

Schritt 4: den Verbrauch je Kunde messen

Der usage-Endpunkt nimmt ein leeres Objekt und liefert den Verbrauch je Schlüssel und je Topf, für alle Schlüssel auf einmal.

# Every key, every bucket, in one call.
curl -X POST http://YOUR_SERVER:8080/admin/keys/usage \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" -d '{}'

{
  "errorId": 0,
  "keys": [
    {
      "name": "cust_10482",
      "key": "a1b2c3d4e5f6...",
      "buckets": [
        {
          "bucket": "Recaptcha",
          "granted": 10000,
          "remaining": 9581,
          "used": 419,
          "failed": 12,
          "inFlight": 3,
          "lastUsed": "2026-08-26T09:14:02.1234567Z"
        }
      ]
    }
  ]
}

Die Zähler laufen über die gesamte Lebensdauer des Schlüssels und überstehen Neustarts. Da ein Aufruf alle Schlüssel liefert, fragen Sie ihn nach Zeitplan ab und füttern damit ein Dashboard, statt ihn je Kunde einzeln aufzurufen. Das Feld lastUsed ist außerdem der Weg, ruhende Schlüssel zu finden, die man zurückholen sollte.

Schritt 5: den Schlüssel bei der Kündigung entziehen

Das Löschen nimmt genau ein Merkmal entgegen, entweder den Wert oder den Namen. Da Sie nach Kunden benannt haben, ist der Name die richtige Wahl:

# By name, which is unambiguous because names are unique.
curl -X POST http://YOUR_SERVER:8080/admin/keys/delete \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" -d '{"name":"cust_10482"}'

# By value works too, if that is what your records hold:
#   -d '{"key":"the-old-value"}'

Der Entzug greift ab der nächsten Anfrage zum Lösen, der Zugang endet also in dem Moment, in dem der Aufruf zurückkehrt. Von da an scheitern die Aufrufe dieses Kunden mit ERROR_KEY_DOES_NOT_EXIST, und das ist ein klares Signal: Die Integration kann es als abgelaufenes Abonnement ausweisen statt als Störung.

Entscheiden Sie bewusst, wann Sie das auslösen. Beim Kündigungs-Ereignis zu löschen kappt den Zugang sofort, obwohl der Kunde meist bis zum Periodenende bezahlt hat. Beim Periodenende zu löschen ist das, was die meisten tatsächlich wollen. Eine fehlgeschlagene Zahlung ist der dritte Fall: eine kurze Kulanzfrist vor dem Entzug erzeugt weit weniger Support-Tickets als ein Schlüssel, der bei einem erneuten Abbuchungsversuch verschwindet.

Schritt 6: die Liste mit Ihrem Billing abgleichen

Der Listenaufruf nimmt ein leeres Objekt und gibt jeden Schlüssel zurück, den die Instanz derzeit akzeptiert.

# The audit: exactly who can solve right now.
curl -X POST http://YOUR_SERVER:8080/admin/keys/list \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" -d '{}'

{
  "errorId": 0,
  "keys": [
    { "name": "cust_10482", "key": "..." },
    { "name": "cust_10515", "key": "..." }
  ]
}

Eine errorId von 0 bedeutet Erfolg, dieselbe Konvention nutzen auch die Endpunkte zum Lösen. Lassen Sie das nach Zeitplan laufen und gleichen Sie die Namen mit Ihren aktiven Abonnements ab. Ein Schlüssel ohne passendes Abonnement bedeutet, dass jemand weiterhin kostenlos löst, und ein Abonnement ohne Schlüssel bedeutet einen Kunden, dessen Bereitstellungs-Webhook verloren ging und der vermutlich gleich ein Ticket öffnet. Beides bleibt still, bis Sie hinsehen, und dieser Aufruf ist der einzige Ort, an dem die Wahrheit steht.

Was Ihre Kunden sehen, wenn ein Limit erreicht ist

Ein Schlüssel ohne Restguthaben in einem Topf bekommt von den Lösungs-Endpunkten ERROR_ZERO_BALANCE, und zwar nur für Aufgaben aus diesem Topf. Jeder andere Topf dieses Schlüssels arbeitet weiter. Der Fehler kommt aus der Lösungs-API, nicht aus dieser Admin-API, und er kommt in allen Emulationen gleich an: 2captcha, Anti-Captcha, CapSolver und DeathByCaptcha. Was ein Kunde also ohnehin schon für ein aufgebrauchtes 2captcha-Guthaben implementiert hat, deckt diesen Fall ohne jede Änderung auf seiner Seite ab.

Auch Guthabenabfragen verhalten sich vernünftig. Ein Kunde, der getBalance oder die Guthaben-Aktion von res.php abfragt, sieht sein echtes Restguthaben, summiert über alle begrenzten Töpfe, die Zahl zählt also mit der Nutzung herunter. Ein Schlüssel ganz ohne Limits meldet weiterhin den alten Platzhalterwert 999999.99, womit Clients, die vor dem Absenden das Guthaben auf Plausibilität prüfen, genau wie bisher funktionieren.

Ein blinder Fleck ist erwähnenswert. Das Übertragungsformat hat nur Platz für eine einzige Zahl, ein Schlüssel mit 50.000 Bildguthaben und null reCAPTCHA-Guthaben meldet also trotzdem ein gesundes Guthaben. Alles, was die Aufschlüsselung nach Typ braucht, muss stattdessen den usage-Endpunkt lesen, und der ist rein administrativ.

Der Einbau in einen Abonnement-Webhook

Zusammengesetzt besteht die ganze Integration aus einer Tariftabelle und vier Handlern:

# pip install requests
import requests

BASE = "http://YOUR_SERVER:8080"
AUTH = {"Authorization": "Bearer YOUR_TOKEN"}

BUCKETS = ("ImageToText", "Recaptcha", "Turnstile", "GeeTest", "Altcha", "CaptchaFox", "Capy", "FriendlyCaptcha")

# None means unlimited; an omitted bucket is unlimited too.
PLANS = {
    "starter":   {"ImageToText": 50_000,  "Recaptcha": 10_000},
    "pro":       {"ImageToText": 500_000, "Recaptcha": 100_000,
                  "Turnstile": 25_000},
    "unlimited": {},
}

def admin(path, body):
    r = requests.post(f"{BASE}/admin/keys/{path}", json=body,
                      headers=AUTH, timeout=10)
    if r.status_code == 409:
        return None          # already exists: a retried webhook
    r.raise_for_status()
    return r.json()

def on_subscription_active(customer_id, plan):
    body = {"name": f"cust_{customer_id}"}
    if PLANS[plan]:
        body["grants"] = PLANS[plan]
    created = admin("add", body)
    return created["key"]["key"] if created else None

def apply_plan(customer_id, plan):
    """Upgrade, downgrade, or start-of-cycle reset."""
    limits = PLANS[plan]
    for bucket in BUCKETS:
        admin("grant", {"name": f"cust_{customer_id}", "bucket": bucket,
                        "mode": "set", "credits": limits.get(bucket)})

def on_subscription_ended(customer_id):
    admin("delete", {"name": f"cust_{customer_id}"})

def usage_report():
    return admin("usage", {})["keys"]

Beachten Sie, dass apply_plan jeden Topf schreibt, statt nur die geänderten zu korrigieren. Das ist Absicht: Bei einem Downgrade räumt es Limits weg, die der alte Tarif hatte und der neue nicht, denn ein fehlender credits-Wert bedeutet im set-Modus unbegrenzt. Für einen Übertragungstarif stellen Sie auf den add-Modus um und überspringen die Töpfe, deren Limit None ist, denn der add-Modus lehnt einen fehlenden oder auf 0 gesetzten Wert ab.

Behandeln Sie das None aus einem wiederholten Abschluss bewusst. Es bedeutet, dass der Schlüssel existiert, Sie seinen Wert aber nicht mehr sehen können. Haben Sie ihn beim ersten Mal nicht gespeichert, führt der Weg über Löschen und neu Anlegen, nicht über das Auflisten. Speichern Sie den Wert gleich beim ersten Empfang, dann entsteht die Situation gar nicht erst.

Lassen Sie die Admin-API nicht auf dem Port liegen, den Kunden sehen

Für dieses Setup ist das der wichtigste Abschnitt, denn die Bequemlichkeit von einem Host und einem Port schneidet in beide Richtungen. Ihre Kunden müssen die Endpunkte zum Lösen erreichen. Die Admin-Endpunkte liegen auf demselben Port, geschützt allein durch den Bearer token, und eine Transportprüfung gibt es nicht, auf einem eigenen Port geht dieser token also im Klartext über HTTP. Wer diesen Verkehr mitlesen kann, liest ihn, und wer ihn besitzt, legt sich selbst einen Schlüssel an.

Setzen Sie einen Reverse Proxy vor die Instanz und trennen Sie die beiden Zielgruppen:

• Veröffentlichen Sie im Internet nur die Pfade zum Lösen, über HTTPS mit Terminierung am Proxy, und geben Sie für alles unterhalb des Admin-Pfads einen 404 zurück.
• Erreichen Sie die Admin-Endpunkte von Ihrem eigenen Backend über einen privaten Weg: über die Loopback-Adresse, wenn Ihr Billing auf demselben Windows-Rechner läuft, sonst über ein privates Netz, ein VPN oder einen SSH-Tunnel.

Die Faustregel lautet: Der Admin-token darf Ihre Infrastruktur nie verlassen, und der Port, mit dem er spricht, darf nie einer sein, den ein Kunde erreicht. Geben Sie den Admin-Pfad niemals ins offene Internet, ob die Funktion nun eingeschaltet ist oder nicht.

Eine weitere Grenze ist wissenswert, denn ein Kundenportal ist hier das Naheliegendste, was man bauen will. Browser können diese Endpunkte nicht aufrufen, denn Admin-Antworten senden bewusst keine CORS -Header. Ihr Dashboard muss über Ihr eigenes Backend laufen, und genau dorthin gehört der token ohnehin.

Wohin die Schlüssel tatsächlich geschrieben werden

Die Schlüssel landen dort, wo Ihre Schlüssel ohnehin liegen. Direct Input und From File sind zwei getrennte Listen, und die API liest und schreibt jeweils die gerade ausgewählte. Wechseln Sie die Quelle im Einstellungsfenster, ändert sich auch, was die Endpunkte sehen. Vergewissern Sie sich also erst, in welchem Modus Sie sind, bevor Sie sich wundern, warum ein eben bereitgestellter Schlüssel nicht in der Liste steht.

Beim Dateimodus lohnt sich ein Hinweis vorab: Der erste Schreibvorgang schreibt eine Klartext-Schlüsseldatei als JSON neu. Es geht nichts verloren, aber das Format ändert sich dauerhaft, sichern Sie die Datei also vorher, falls noch etwas anderes sie liest. Ist überhaupt keine Datei ausgewählt, kann ein Schreibvorgang nirgends landen und Sie bekommen ERROR_ADMIN_STORE_FAILURE mit einem 500. Fast immer bedeutet ein 500 an dieser Stelle genau das.

Listen, die es schon vor dieser Funktion gab, können weiterhin doppelte Namen enthalten, weil die Eindeutigkeit nur beim Anlegen geprüft wird. Ein Löschen per Name trifft dort auf ERROR_KEY_NAME_AMBIGUOUS und ändert nichts. Löschen Sie stattdessen über den Wert, dann ist die Mehrdeutigkeit weg.

Anführungszeichen in der Windows-Shell, falls Sie direkt auf dem Rechner testen

CapSkip ist eine Windows-Anwendung, der Rechner, von dem aus Sie testen, läuft also oft ebenfalls unter Windows. Die Eingabeaufforderung behandelt das einfache Anführungszeichen nicht als Anführungszeichen. Der kopierte Befehl schickt die Zeichen als Teil des JSON-Bodys mit, der Parser lehnt ab, und Sie bekommen ERROR_ADMIN_BAD_REQUEST bei einem Befehl, der völlig korrekt aussieht.

Rufen Sie curl.exe in PowerShell mit vollem Namen auf. Das schlichte curl ist dort ein Alias für Invoke-WebRequest, das ganz andere Argumente erwartet und auf eine Weise scheitert, die mit dieser API nichts zu tun hat.

Fehlercodes

Ein weiterer Code gehört hierher, auch wenn er von der anderen Seite des Produkts kommt. ERROR_ZERO_BALANCE liefern die Lösungs-Endpunkte, nicht diese Admin-API, und zwar dann, wenn einem Schlüssel in dem Topf, zu dem die Aufgabe gehört, das Guthaben ausgegangen ist. Meldet ein Kunde ihn, lautet die Antwort Aufstocken und nicht, dass an der Bereitstellung etwas kaputt wäre.

Diese Codes stehen neben den Fehlercodes fürs Lösen, sie ersetzen sie nicht, und der vollständige Satz steht in der CapSkip API-Dokumentation.

FAQ

Die kürzeste Fassung

Schalten Sie Remote Key Management einmal ein und bewahren Sie den token bei Ihren übrigen Billing-Geheimnissen auf. Legen Sie einen nach dem Kunden benannten Schlüssel an, sobald dessen Abonnement aktiv wird, gleich mit den grants seines Tarifs, und behandeln Sie den 409 bei einer Wiederholung als Erfolg. Setzen oder stocken Sie diese Limits aus Ihrem Verlängerungs-Webhook auf, denn hier läuft nichts nach Kalender. Fragen Sie den usage-Endpunkt nach Zeitplan ab, sowohl zur Abrechnung als auch, um ruhende Schlüssel zu finden. Löschen Sie über den Namen, wenn das Abonnement endet, und gleichen Sie die Schlüsselliste mit Ihren aktiven Abonnenten ab, denn nur dort steht die echte Antwort. Setzen Sie dann einen Proxy davor und halten Sie den Admin-Pfad von dem Port fern, den Ihre Kunden sehen. Tun Sie das, dann wird Captcha-Umgehung zu etwas, das Sie auf eigener Hardware weiterverkaufen können, gemessen an Ihren eigenen Zahlen und bereitgestellt so schnell, wie Ihre Kasse einen Webhook auslösen kann.