Beta-Hinweis: Diese API-Dokumentation ist Beta. Endpunkte, Felder, Fehlercodes und Verhaltensweisen können sich ohne Vorankündigung ändern, und Abwärtskompatibilität ist nicht garantiert. Verlassen Sie sich nicht darauf für kritische Produktionsabläufe.

Erste Schritte mit unserer RESTful API

Die Dynadot API ist für die nahtlose Integration in deine Systeme konzipiert. Unsere API bietet vorhersehbare ressourcenorientierte URLs, unterstützt JSON-kodierte Anfrageinhalte, liefert JSON- und XML-kodierte Antworten und hält sich an Standard-HTTP-Methoden, Authentifizierung und Antwortcodes.

Du kannst die Dynadot API sowohl im Test- als auch im Live-Modus verwenden. Der Modus wird durch den API-Schlüssel bestimmt, der zur Authentifizierung deiner Anfragen verwendet wird. Der Testmodus ermöglicht es dir, deine API-Integration zu simulieren und zu validieren, ohne Live-Daten oder Transaktionen zu beeinflussen.

Die Dynadot-API konzentriert sich in erster Linie auf Domainverwaltung, Bestellabwicklung und damit verbundene Dienste. Sie können Aktionen wie das Registrieren, Übertragen und Verlängern von Domains, die Verwaltung von DNS-Einstellungen sowie das Anzeigen oder Aktualisieren von Kontobestellungen durchführen.

Bitte beachten Sie: Massen-Erstellungen, -Aktualisierungen und -Löschungen werden nicht unterstützt, und jede dieser Anforderungsarten ist auf ein Objekt oder eine Aktion beschränkt.

Deine API-Schlüssel generieren

Bevor du mit API-Anfragen beginnst, ist es wichtig, deinen API-Schlüssel und dein API-Secret zu generieren.

Diese Schlüssel sind für die Authentifizierung erforderlich und um die Sicherheit Ihrer Aktionen bei der Interaktion mit unserer API zu gewährleisten.

Du kannst sowohl den API-Schlüssel als auch das API-Secret über den API-Bereich in deinen Kontoeinstellungen generieren.

1. Melden Sie sich in Ihrem Konto bei Dynadot an.

2. Navigiere zu Werkzeuge > API.

3. Generiere deinen API-Schlüssel und API-Secret auf dieser Seite.

Komm in unsere Community

Haben Sie Ideen oder Vorschläge? Sprechen Sie direkt mit unseren professionellen Ingenieuren.

Discord

HTTP-Methode

Die API verwendet Standard-HTTP-Methoden, um Vorgänge an Ressourcen durchzuführen:

MethodeBeschreibung
GETGET-Anfrage: Detaillierte Informationen zu einer bestimmten Ressource abrufen
POSTPOST-Anfrage: Eine neue Ressource erstellen
PUTPUT-Anfrage: Die angegebene Ressource vollständig aktualisieren
DELETEDELETE-Anfrage: Angegebene Ressource entfernen

URL

Die Basis-URL für alle API-Anfragen ist:

https://api.dynadot.com/

Das vollständige URL-Format:

http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action
Beispiel:
https://api.dynadot.com/restful/v2/domains/{domain_name}/search

Version

Die aktuelle Version der API ist v2.0.0

Beim Erstellen der API-Anfrage-URL ist es nur erforderlich, die Hauptversion anzugeben. Minor- und Patch-Updates sind so konzipiert, dass sie abwärtskompatibel sind und keine Änderungen einführen, die Ihren vorhandenen Code beeinträchtigen. Dies gewährleistet Stabilität und ermöglicht es Ihnen, von inkrementellen Verbesserungen und Korrekturen zu profitieren, ohne Ihre Implementierung ändern zu müssen.

Wenn zukünftige Versionen veröffentlicht werden, werden wir die Abwärtskompatibilität für ältere Versionen für einen gewissen Zeitraum beibehalten. Neue Funktionen und Breaking Changes werden in Hauptversionen eingeführt.

Kopfzeile

Der Header einer API-Anfrage enthält Metadaten über die Anfrage. Diese Metadaten liefern wichtigen Kontext, damit der Server die Anfrage ordnungsgemäß verarbeiten kann. Häufig verwendete Header sind:

Content-Type

Gibt das Format der Daten an, die im Anfrage-Body gesendet werden. Der Server verwendet diese Informationen, um die Anfrage korrekt zu parsen. Derzeit ist der einzige akzeptable Wert: application/json

Beispiel:
Content-Type: application/json

Akzeptieren

Informiert den Server über das vom Client erwartete Antwortformat.

Mögliche Werte: application/json, application/xml

Beispiel:
Accept: application/json

Autorisierung

Alle API-Anfragen müssen einen API-Schlüssel zur Authentifizierung enthalten. Du kannst deinen API-Schlüssel in deinem Account-Dashboard abrufen.

Sie können einen API-Schlüssel auf der API-Einstellungsseite generieren
Beispiel für Authentifizierungs-Header :
Authorization: Bearer YOUR_API_KEY

X-Request-ID

Der X-Request-ID-Header ist ein (Optional)-Header, der verwendet wird, um jede API-Anfrage eindeutig zu identifizieren. Wenn er enthalten ist, hilft dieser Header dabei, Anfragen über Systeme und Protokolle hinweg zu verfolgen und zu korrelieren, was das Debuggen und Überwachen der API-Aktivität erleichtert.

Der Wert der X-Request-ID muss eine gültige UUID (Universally Unique Identifier) sein und dem Standardformat folgen: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (z. B. 123e4567-e89b-12d3-a456-426614174000).

Beispiel:
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000

X-Signature Neu

Der X-Signature-Header ist ein obligatorischer Sicherheitsmechanismus für transaktionale Anfragen, einschließlich solcher, die sensible Informationen abrufen oder Daten aktualisieren. Er gewährleistet die Authentizität, Integrität und Nichtabstreitbarkeit von API-Anfragen, indem er von den Clients verlangt, die Anfrage-Payload mit HMAC-SHA256 zu signieren.

Um die Signatur zu generieren, benötigen Sie die folgenden Werte

1. API-Schlüssel: Dein eindeutiger API-Schlüssel.

2. Vollständiger Pfad und Abfrage: Der vollständige Pfad des API-Endpunkts zusammen mit den Abfrageparametern.

3. X-Request-Id: Die Anfrage-ID. Falls sie nicht verfügbar ist, kannst du eine leere Zeichenkette eingeben.

4. Request-Body: Der Body der Anfrage. Wenn er leer oder null ist, kannst du einen leeren String eingeben.

Die zu signierende Zeichenfolge ist eine Kombination der oben genannten Werte, die in der folgenden Reihenfolge verkettet werden:

apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Beispiel
apiKey = "your_api_key"
fullPathAndQuery = "/restful/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"

stringToSign = "your_api_key\n/restful/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"
HMAC-SHA256-Signatur generieren

Nachdem du stringToSign erstellt hast, berechne die Signatur mit HMAC-SHA256, wobei dein Geheimnis als Schlüssel dient, und Base64-kodieren dann das Ergebnis.

Die Signatur wird mit den folgenden Schritten generiert:

1. Verwende den HMAC-SHA256-Algorithmus.

2. Verwenden Sie stringToSign (UTF-8) als Eingabenachricht.

3. Verwende dein Secret (UTF-8) als Schlüssel.

4. Kodiere die HMAC-Ausgabe in Base64 (Standard-Base64)

Setze das generierte Unterschrift als Wert von X-Signature im Request-Header ein

Example :
X-Signature: {HMAC-SHA256 Signature}
Example Code :
import base64
import hashlib
import hmac
import uuid

def create_signature(api_key, api_secret, full_path_and_query, x_request_id, request_body=""):
    string_to_sign = (
        api_key + "\n" +
        full_path_and_query + "\n" +
        (x_request_id or "") + "\n" +
        (request_body or "")
    )

    digest = hmac.new(
        api_secret.encode("utf-8"),
        string_to_sign.encode("utf-8"),
        hashlib.sha256
    ).digest()

    return base64.b64encode(digest).decode("utf-8")

api_key = "your_api_key"
api_secret = "your_secret"
full_path_and_query = "/restful/v2/accounts/info"
x_request_id = str(uuid.uuid4())
request_body = ""

x_signature = create_signature(
    api_key,
    api_secret,
    full_path_and_query,
    x_request_id,
    request_body
)

print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)

Body

Der Body einer API-Anfrage wird verwendet, um Daten an den Server zu senden. Er ist üblicherweise in POST-, PUT- oder PATCH-Anfragen enthalten (normalerweise nicht bei GET- oder DELETE-Anfragen).

Inhaltsformat

Das Format der Body-Daten wird durch den Content-Type-Header bestimmt. Zu den gängigen Formaten gehören:

JSON

Typische Anwendungsfälle

POST-Anfragen: Die POST-Methode wird verwendet, um eine neue Ressource auf dem Server zu erstellen. Der Request-Body enthält normalerweise die Details der Ressource..

PUT-Anfragen: Die PUT-Methode wird verwendet, um eine vorhandene Ressource zu aktualisieren, indem sie vollständig ersetzt wird. Der Request-Body enthält die vollständige aktualisierte Ressource.

DELETE-Anfragen: Die DELETE-Methode wird verwendet, um eine vorhandene Ressource vom Server zu entfernen. Es hat keinen Request-Body.

GET-Anfragen: Die GET-Methode wird verwendet, um eine vorhandene Ressource vom Server abzurufen. Es hat keinen Request-Body

Antwortformat

Alle API-Antworten werden entweder im JSON- oder XML-Format zurückgegeben; welches Format die Body-Daten haben, wird durch den Accept-Header bestimmt, und die Antwort enthält die angeforderten Daten oder gegebenenfalls eine Fehlermeldung.

Inhaltsformat

Die Antwort besteht im Allgemeinen aus 3 Teilen: Code, Nachricht, Daten

Code: Der Status der Anfrage

Nachricht: Weitere Beschreibung des Status

Daten: Der Body der Antwort

JSON/XML

Fehlerbehandlung

HTTP-Statuscodes sind standardisierte dreistellige Zahlen, die ein Server zurückgibt, um das Ergebnis einer Client-Anfrage anzuzeigen. Sie liefern wichtige Informationen darüber, ob die Anfrage erfolgreich verarbeitet wurde, weitere Aktionen erfordert oder auf einen Fehler gestoßen ist. Diese Codes sind in fünf Kategorien unterteilt, von denen jede einen bestimmten Antworttyp darstellt.

Die Statuscodes unserer API folgen dem HTTP/1.1-Protokoll, einem weithin akzeptierten Standard, der eine konsistente und zuverlässige Kommunikation gewährleistet. Durch die Verwendung von HTTP/1.1 nutzen wir Funktionen wie persistente Verbindungen und verbessertes Caching, um die Client-Server-Interaktionen zu optimieren.

2xx (Erfolgreich): Zeigt an, dass der Befehl empfangen und akzeptiert wurde
4xx (Client Error): Signalisiert, dass der Client einen Fehler in der Anfrage gemacht hat, z. B. durch ungültige Eingaben oder fehlende ordnungsgemäße Autorisierung.
5xx (Serverfehler): Zeigt an, dass der Server auf einen Fehler gestoßen ist oder die Anfrage nicht erfüllen kann.

Webhook-Übersicht

Webhooks sind ein leistungsstarkes Werkzeug zum Automatisieren von Prozessen und Integrieren von Systemen. Sie ermöglichen es Ihnen, Echtzeitbenachrichtigungen über Ereignisse oder Änderungen in Ihrem Konto oder Ihren Domaineinstellungen zu erhalten. Durch die Konfiguration von Webhooks können Sie Aktionen in externen Systemen auslösen, Datenbanken aktualisieren oder Benachrichtigungen basierend auf bestimmten Ereignissen senden.

Die Dynadot API unterstützt Webhook-Benachrichtigungen für verschiedene Ereignisse wie Domainregistrierung, Transfer, Verlängerung und Ablauf, sodass du entsprechend reagieren kannst.

Um Webhooks zu verwenden, musst du einen URL-Endpunkt angeben, an den die Benachrichtigungen gesendet werden. Du kannst deine Webhook-URL, deinen Schlüssel und dein Secret in deinen Kontoeinstellungen konfigurieren. Wenn ein Ereignis eintritt, sendet Dynadot eine POST-Anfrage mit den relevanten Daten an die angegebene URL.

Webhook-Anfrage-Header

Der Header einer Webhook-Anfrage enthält Metadaten über die Anfrage. Diese Metadaten liefern dem Server wichtigen Kontext, um die Anfrage korrekt zu verarbeiten. Häufig verwendete Header sind:

Content-Type

Gibt das Format der Daten an, die im Anfrage-Body gesendet werden. Der Server verwendet diese Informationen, um die Anfrage korrekt zu parsen. Derzeit ist der einzige akzeptable Wert: application/json

Beispiel:
Content-Type: application/json

Autorisierung

Alle Webhook-Anfragen enthalten einen Webhook-Schlüssel zur Authentifizierung. Ihren Webhook-Schlüssel finden Sie im Dashboard Ihres Kontos.

Sie können Ihren WEBHOOK_KEY auf der API-Einstellungsseite verwalten
Beispiel für Authentifizierungs-Header :
Authorization: Bearer WEBHOOK_KEY

X-Signature

Der X-Signature-Header ist ein obligatorischer Sicherheitsmechanismus für transaktionale Anfragen, einschließlich derer, die sensible Informationen abrufen oder Daten aktualisieren. Er stellt Authentizität, Integrität und Nichtabstreitbarkeit von Webhook-Anfragen sicher, indem Clients die Anfrage-Payload mit HMAC-SHA256 signieren müssen.

Um die Signatur zu generieren, benötigen Sie die folgenden Werte

1. WEBHOOK-Schlüssel: Ihr eindeutiger WEBHOOK-Schlüssel.

2. Vollständiger Pfad und Abfrage: Der vollständige Pfad des Webhook-Endpunkts zusammen mit den Query-Parametern.

3. X-Request-Id: Die Anfrage-ID. Falls sie nicht verfügbar ist, kannst du eine leere Zeichenkette eingeben.

4. Request-Body: Der Body der Anfrage. Wenn er leer oder null ist, kannst du einen leeren String eingeben.

Die zu signierende Zeichenfolge ist eine Kombination der oben genannten Werte, die in der folgenden Reihenfolge verkettet werden:

webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Beispiel
webhookKey = "your_webhook_key"
fullPathAndQuery = "/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"

stringToSign = "your_webhook_key\n/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"
HMAC-SHA256-Signatur generieren

Nachdem du stringToSign erstellt hast, berechne die Signatur mit HMAC-SHA256, wobei dein Geheimnis als Schlüssel dient, und Base64-kodieren dann das Ergebnis.

Die Signatur wird mit den folgenden Schritten generiert:

1. Verwende den HMAC-SHA256-Algorithmus.

2. Verwenden Sie stringToSign (UTF-8) als Eingabenachricht.

3. Verwende dein Secret (UTF-8) als Schlüssel.

4. Kodiere die HMAC-Ausgabe in Base64 (Standard-Base64)

Setze das generierte Unterschrift als Wert von X-Signature im Request-Header ein

Example :
X-Signature: {HMAC-SHA256 Signature}
Example Code :
import base64
import hashlib
import hmac
import uuid

def create_signature(webhook_key, webhook_secret, full_path_and_query, x_request_id, request_body=""):
    string_to_sign = (
        webhook_key + "\n" +
        full_path_and_query + "\n" +
        (x_request_id or "") + "\n" +
        (request_body or "")
    )

    digest = hmac.new(
        webhook_secret.encode("utf-8"),
        string_to_sign.encode("utf-8"),
        hashlib.sha256
    ).digest()

    return base64.b64encode(digest).decode("utf-8")

webhook_key = "your_webhook_key"
webhook_secret = "your_secret"
full_path_and_query = "/v2/some/webhook/path"
x_request_id = str(uuid.uuid4())
request_body = ""

x_signature = create_signature(
    webhook_key,
    webhook_secret,
    full_path_and_query,
    x_request_id,
    request_body
)

print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)

Webhook-Anfrageformat

Inhaltsformat

Der Body einer Webhook-Anfrage enthält Informationen über das Ereignis, das die Benachrichtigung ausgelöst hat. Das Format der Body-Daten wird durch den Content-Type-Header bestimmt, der typischerweise application/json ist.

Der Body der Anfrage enthält die folgenden Parameter:

Beispiel:

JSON/XML

Parameter

Der Body der Anfrage enthält die folgenden Parameter:

ParameterBeschreibung
EreignisDer Typ des Ereignisses, das die Benachrichtigung ausgelöst hat.
event_idDie ID des Ereignisses, das die Benachrichtigung ausgelöst hat.
ZeitstempelDer Zeitstempel, zu dem das Ereignis aufgetreten ist.
DatenDie mit dem Ereignis verknüpften Daten.

Webhook-Antwortformat

Inhaltsformat

Die Antwort auf eine Webhook-Anfrage wird im JSON-Format gesendet, abhängig vom Content-Type-Header, der in der Anfrage angegeben ist.

Der Antwort-Body enthält Informationen zum Status der Anfrage, z. B. ob sie erfolgreich verarbeitet wurde oder ein Fehler aufgetreten ist.

Die Antwort enthält im Allgemeinen 1 Teil: Status

Beispiel:

JSON/XML

Ratenbegrenzung

Anfragen sollten aus Sicherheitsgründen über https (Secure Socket) gesendet werden. Es kann immer nur 1 Anfrage gleichzeitig verarbeitet werden. Bitte warte also, bis deine aktuelle Anfrage abgeschlossen ist, bevor du eine weitere Anfrage sendest.

Sie erhalten je nach Preisstufe Ihres Kontos unterschiedliche Thread-Anzahlen:

PreisstufeThread-AnzahlRatenlimit
Regulär1 Thread60/min (1/sec)
Bulk5 Threads600/Min. (10/Sek.)
Super Bulk35 Threads6000/Min. (100/Sek.)

Hinweis: place_auction_bid & get_auction_bid sind derzeit von der oben genannten Ratenbegrenzung ausgenommen.

Beispiel:

Für den Domain Appraisal Command erhalten Sie je nach Preisstufe Ihres Kontos unterschiedliche erlaubte Anfrageanzahlen:

PreisstufeRatenlimit
Regulär50/Tag
Bulk100/Tag
Super Bulk300/Tag
Beispiel:

Sandbox

Die Dynadot API-Sandbox-Umgebung ermöglicht es Ihnen, Ihre API-Integrationen sicher zu testen, ohne Ihr Live-Konto oder echtes Guthaben zu beeinträchtigen.

Zugriff auf die Sandbox

1. Melden Sie sich in Ihrem Dynadot-Konto an und navigieren Sie zur Seite mit den API-Einstellungen:

2. https://www.dynadot.com/account/domain/setting/api.html

3. Generieren Sie Ihren API Sandbox Key und Ihren API Sandbox Secret Key.

4. Bitte geben Sie dem System nach der Generierung etwas Zeit, Ihre Sandbox-Schlüssel zu aktivieren und Ihr Sandbox-Konto zu erstellen.

5. Ihr Sandbox-Konto wird zu Testzwecken mit einem Guthaben von 10.000 in allen unterstützten Währungen vorab aufgeladen.

Die Sandbox-API verwenden

Die API-Befehle in der Sandbox-Umgebung funktionieren genauso wie in der Produktionsumgebung.

Der einzige Unterschied ist die Basis-URL:

Produktions-API-URL: https://api.dynadot.com

URL der Sandbox-API: https://api-sandbox.dynadot.com

Wichtige Hinweise

Einige API-Befehle sind in der Sandbox-Umgebung möglicherweise nicht verfügbar. Bitte schau in der Dokumentation zum jeweiligen Befehl nach, um zu prüfen, ob das Label "Support API Sandbox" vorhanden ist.

Die Sandbox ist in erster Linie zum Testen gedacht. Bestimmte Befehle können von der Produktionsumgebung abweichen, und die Sandbox kann nicht alle möglichen komplexen Szenarien vollständig simulieren, die in der Produktionsumgebung zu finden ist.

Überblick über das Änderungsprotokoll

Ein Änderungsprotokoll ist eine detaillierte Aufzeichnung von Änderungen, Verbesserungen, Fehlerbehebungen und neuen Funktionen, die in jeder Version der API eingeführt wurden. Es sorgt für Transparenz bei Nutzern und Entwicklern, indem es die Auswirkungen jedes Updates dokumentiert. Es besteht aus zwei wichtigen Teilen:

API-Version

Dieser Teil hebt das Versionssystem der API hervor, das Entwicklern hilft, die Entwicklung von Funktionen zu verfolgen und Kompatibilität sicherzustellen. Jede API-Version wird durch eine eindeutige Versionsnummer identifiziert (z. B. v1.0.1, v2.2.3) und stellt einen bedeutenden Meilenstein oder eine Veröffentlichung dar. Die Versionierung ermöglicht es Benutzern, Integrationen mit minimalen Störungen beizubehalten, indem sie sich für Updates entscheiden, wenn sie bereit sind.

Änderungsverlauf

Die Change-Log-Historie bietet detaillierte Informationen über Updates, Bugfixes, Deprecations und Verbesserungen, die in jeder Version eingeführt wurden. Sie beschreibt konkrete Änderungen an Endpunkten, Parametern, Authentifizierungsmechanismen oder Antwortformaten. Dieser Abschnitt sorgt dafür, dass Entwickler vollständige Transparenz darüber haben, was sich geändert hat, und ihre Implementierungen entsprechend anpassen können. Durch die Pflege eines klaren und detaillierten Change-Logs möchten wir Entwicklern die Werkzeuge und Informationen an die Hand geben, die sie benötigen, um Integrationen effektiv und souverän zu verwalten.

API-Version

Unsere API befindet sich derzeit in Version v2.0.0

Versionscodes werden verwendet, um API-Aktualisierungen systematisch zu identifizieren und zu verwalten. Sie folgen dem Format der semantischen Versionierung (SemVer):

<Major><Minor><Patch>

Jede Komponente des Versionscodes dient einem bestimmten Zweck und hilft Entwicklern, den Umfang und die Art der Änderungen effektiv zu kommunizieren.

Hauptversion

Definition: Steht für wesentliche Änderungen, die die Abwärtskompatibilität beeinträchtigen können.

Format:

x.<Minor>.x
Beispiele: v1.0.0 -> v2.0.0: Ein komplettes API-Redesign oder inkompatible Schemaänderungen.

Minor-Version

Definition: Kennzeichnet rückwärtskompatible Funktionserweiterungen.

Format:

x.<Minor>.x
Beispiele: v1.0.0 -> v1.1.0: Neue Endpunkte oder Methoden hinzufügen, während die Abwärtskompatibilität erhalten bleibt.

Patch-Version

Definition: Bezieht sich auf abwärtskompatible Fehlerbehebungen oder kleinere Verbesserungen.

Format:

x.x.<Patch>
Beispiele: v1.0.0 -> v1.1.0: Behebung eines kleinen Fehlers in einem API-Endpunkt.

API-Änderungsprotokoll

Ein Änderungsprotokoll ist eine detaillierte Aufzeichnung von Änderungen, Verbesserungen, Fehlerbehebungen und neuen Funktionen, die in jeder Version einer Software oder einer API eingeführt werden. Es bietet Transparenz für Benutzer und Entwickler, indem es die Auswirkungen jedes Updates dokumentiert.

Ein typischer Eintrag in einem Änderungsprotokoll enthält:

Beschreibung: Eine kurze Erklärung, was geändert wurde.

Betroffene Komponenten: Bestimmte Module, Endpunkte oder Funktionen, die von der Änderung betroffen sind.

Beispiel: Unterstützung für diesen neuen API-Befehl <Domain registrieren> hinzugefügt

Änderungsverlauf

Behalten Sie jede Änderung an der Dynadot API im Auge.

9. Oktober 2025
v2.0.0Neue Funktionen & wichtige Änderungen Sandbox-Umgebung jetzt live Die Sandbox-Umgebung ist offiziell gestartet und steht für sichere Tests und Integrationsvalidierung zur Verfügung. Obligatorischer X-Signature-Header für sensible Vorgänge Um die Sicherheit zu erhöhen, wird der X-Signature-Header jetzt für alle sensiblen API-Befehle erzwungen. (Optional) Maschinenlesbare API-Dokumentation Wir unterstützen jetzt strukturierte, maschinenlesbare API-Dokumentation für eine einfachere Integration mit automatisierten Tools. Suchzugriff eingeschränkt Der Zugriff auf bestimmte suchbezogene Endpunkte wurde aus Gründen der Leistung und Datenkontrolle eingeschränkt. IP-Whitelisting optimiert Reseller-Konto muss nicht mehr mindestens 1 IP eingeben, um die API zu nutzen (nur RESTful API) Verbesserungen der API-Dokumentation Aktualisierte Versionsauswahl auf der Dokumentations-Startseite für einfachere Navigation Einheitliche Groß- und Kleinschreibung bei Parameternamen Erweiterte Dokumentation und Nutzungshinweise für den bulk_search-Endpunkt Funktion zum Ausblenden/Einblenden der Seitennavigation hinzugefügt
Obligatorische Paging-Parameter eingeführt, um die Antworteffizienz und -konsistenz zu verbessern. page (integer, required) – Gibt den aktuellen Seitenindex an, beginnend bei 1. page_size (Ganzzahl, erforderlich) – Definiert die Anzahl der pro Seite zurückgegebenen Elemente.get_listings