Kostenpflichtige Vorgänge

Idempotency-Key

POST /orders und POST /orders/{id}/renew erwarten für jeden Vorgang einen eindeutigen Idempotency-Key-Header. Bei einem Timeout ist eine Wiederholung mit demselben Wert sicher: Die abgeschlossene Anfrage wird erneut zurückgegeben (meta.idempotent_replay: true), und es wird nie doppelt abgebucht.

Idempotency-Key: 3f7a1c9e-2b48-4d51-9c3a-8e6f0d215b47

import { randomUUID } from "node:crypto";

const key = randomUUID(); // bei jedem erneuten Versuch DERSELBE Wert

async function createOrder(body) {
  for (let attempt = 0; attempt < 3; attempt++) {
    const res = await fetch("https://api.proxynet.io/api/v1/orders", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.PROXYNET_TOKEN}`,
        "Idempotency-Key": key,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
    });
    if (res.status === 409 && res.headers.get("retry-after")) {
      await new Promise((r) => setTimeout(r, Number(res.headers.get("retry-after")) * 1000));
      continue;
    }
    return res.json();
  }
}

import os, time, uuid, requests

key = str(uuid.uuid4())  # bei jedem erneuten Versuch DERSELBE Wert

def create_order(body):
    for _ in range(3):
        res = requests.post(
            "https://api.proxynet.io/api/v1/orders",
            headers={
                "Authorization": f"Bearer {os.environ['PROXYNET_TOKEN']}",
                "Idempotency-Key": key,
            },
            json=body,
        )
        if res.status_code == 409 and "Retry-After" in res.headers:
            time.sleep(int(res.headers["Retry-After"]))
            continue
        return res.json()

Wann ein Schlüssel wieder frei wird

• Ein Schlüssel wird nur freigegeben, wenn der Versuch mit Sicherheit nichts abgebucht hat: bei einer Ablehnung mit 4xx oder einem Anbieterfehler, dessen Betrag erstattet wurde (details.refunded: true). In diesem Fall startet derselbe Schlüssel einen neuen Versuch.
• Ein Schlüssel gilt für genau einen Vorgang. Denselben Schlüssel mit einem anderen Body (einschließlich Zielen, Name und Optionen) zu senden oder ihn für eine andere Bestellung oder Verlängerung zu verwenden, liefert 400 invalid_request. Ein Schlüssel, mit dem eine Bestellung aufgegeben wurde, wird bei einer Verlängerung nicht akzeptiert, ein für eine Verlängerung verwendeter Schlüssel nicht bei einer Bestellung.
• Ein 409 conflict mit details.order_id zeigt, dass die mit diesem Schlüssel aufgegebene Bestellung nicht mehr aktiv ist (sie ist fehlgeschlagen, ohne dass eine automatische Erstattung möglich war, oder wurde storniert). Verwenden Sie einen neuen Schlüssel; wurde ein Betrag abgebucht, wenden Sie sich an den Support.

Ist die Bestellung bereit?

meta.ready gibt an, ob die Bestellung bereits aktiv ist, auch in einer wiederholten Antwort. Bei einer Vorbestellung, einer geplanten Aktivierung oder einer Verzögerung beim Anbieter ist der Wert false, und meta.warning ist gefüllt. Geben Sie die Bestellung dann noch nicht zur Nutzung frei; fragen Sie GET /orders/{id} ab, bisstate den Wert active hat.

Anmeldedaten

Benutzername und Passwort sind optional. Senden Sie sie nicht mit, erzeugt das System sie; hat das Token auch proxies:read, kommen sie in der Antwort zurück. Um sie selbst zu wählen, muss Ihre Stufe das erlauben: siehe das Feld plan.custom_credentials in der Antwort von /me.

Bestellfelder nach Typ

✓ wird akzeptiert, ✓* ist Pflicht, — wird bei diesem Typ nicht verwendet; der Wert in Klammern ist der Standardwert, wenn das Feld fehlt. Unbekannte Felder werden abgelehnt; ein Tippfehler wird nicht stillschweigend ignoriert.

Änderungen an Einstellungen

Änderungen an Einstellungen wie Dienstname und Traffic-Limit kosten kein Geld und erfordern eine eigene Berechtigung (proxies:write). Einen Idempotency-Key benötigen sie nicht.