DynDNS-API: Domains und Records per API verwalten

Mit der API von IPv64.net verwaltest du dein Konto per Skript: Domains und DNS-Records anlegen und löschen, Cloud Router abfragen. Diese Seite beschreibt die bisherige API (v1, api.php) mit allen Aktionen und curl-Beispielen; für neue Projekte gibt es die API v2.

Die API v1 auf einen Blick

• Adresse: https://ipv64.net/api.php oder https://ipv64.net/api
• Aufbau: Die Aktion steht als Parameter in der Anfrage, z. B. ?get_domains. Abfragen gehen per GET, Anlegen per POST (Formulardaten), Löschen per DELETE mit application/x-www-form-urlencoded-Body.
• Antwort: immer JSON.
• Anmeldung: mit einem API-Key (32 Zeichen).

Für das reine IP-Update von Routern und einfachen Geräten ist die API nicht gedacht – dafür gibt es die Update-URL.

Authentifizierung mit API-Key

Die API nimmt zwei Arten von Keys an:

• API-Keys aus Account > API – mit Namen und optionalem Ablaufdatum, beliebig viele. Am besten einen eigenen Key pro Gerät oder Skript.
• den Account-API-Key deines Kontos (siehe Konto & Limits).

Den Key schickst du auf einem dieser Wege mit:

1. Header (empfohlen)
   Authorization: Bearer DEIN_API_KEY (auch Authorization: Token …)
2. HTTP Basic Auth
   Benutzername oder Passwort ist der Key (32 Zeichen), das andere Feld ist beliebig.
3. Parameter
   apikey, key oder token per GET oder POST.

Fehlt der Key oder ist er falsch, antwortet die API mit 401 und "info":"Unauthorized". Ist ein API-Key abgelaufen, steht in info API Key is expired. Das Konto muss aktiviert sein.

Limits

• Kurzzeit-Limit: höchstens 5 API-Aufrufe innerhalb von 5 Sekunden je Konto. Darüber antwortet die API mit 429 und "info":"Updateintervall overcommited".
• Tageslimit: Free 512 Aufrufe pro Tag; Home / Supporter, Business und Company unbegrenzt (siehe Konto & Limits). Ist es erreicht, kommt 429 mit "info":"API Limit". Jeder angemeldete Aufruf zählt, auch einer, der am Kurzzeit-Limit scheitert. Der Zähler wird täglich zurückgesetzt.

Die Zahl der Aufrufe eines Keys siehst du in Account > API in der Spalte „Used“.

Antworten und Statuscodes

Jede Antwort ist ein JSON-Objekt mit

• info – success oder error (bei Anmelde- und Limitfehlern ein Text),
• status – HTTP-Code als Text, z. B. "201 Created",
• einem Feld mit dem Namen der Aktion oder einer Fehlerbeschreibung, z. B. "add_domain":"domain limit reached",
• und den eigentlichen Daten.

Schickt eine Anfrage keine bekannte Aktion mit, enthält die Antwort keine Daten.

Konto-Informationen und Logs

get_account_info

Liefert die Daten deines Kontos: E-Mail, Status, Gültigkeit der Kontoklasse, Registrierungsdatum, Zähler (DynDNS-Updates, API-Aufrufe, Healthcheck-Pings, SMS, CDN- und VPN-Traffic), Anzahl Domains und Healthchecks sowie unter account_class die Limits deiner Kontoklasse (dyndns_domain_limit, dyndns_update_limit, dyndns_ttl, api_limit …). Die Zähler cdn_traffic_input und cdn_traffic_output enthalten nicht den Traffic von CDN64; den liefert die CDN64-API.

curl "https://ipv64.net/api.php?get_account_info" -H "Authorization: Bearer DEIN_API_KEY"

get_logs

Die letzten 100 Einträge aus dem Konto-Log, jeweils mit subdomain, time, header und content.

curl "https://ipv64.net/api.php?get_logs" -H "Authorization: Bearer DEIN_API_KEY"

Domains abfragen, anlegen und löschen

get_domains

Alle Domains mit ihren Records. Pro Domain: updates, wildcard, domain_update_hash (Domain-Key), ipv6prefix, dualstack, deactivated und records. Jeder Record hat record_id, content, ttl, type, praefix, last_update, record_key, deactivated und failover_policy.

curl "https://ipv64.net/api.php?get_domains" -H "Authorization: Bearer DEIN_API_KEY"

Antwort (gekürzt):

{
  "subdomains": {
    "deinedomain.ipv64.net": {
      "updates": "42", "wildcard": "1", "deactivated": "0",
      "records": [
        {"record_id": "1234", "type": "A", "praefix": "", "content": "192.0.2.10", "ttl": "60"}
      ]
    }
  },
  "info": "success", "status": "200 OK"
}

add_domain (POST)

Legt eine Domain an, z. B. add_domain=deinedomain.ipv64.net. Endet der Name auf eine der Domain-Endungen von IPv64.net, entsteht eine DynDNS-Domain; sonst wird er als eigene Domain (nur DNS) angelegt – dafür braucht deine Kontoklasse ein Kontingent an eigenen Domains.

curl -X POST "https://ipv64.net/api.php" -H "Authorization: Bearer DEIN_API_KEY" \
  -d "add_domain=deinedomain.ipv64.net"

Fehler (403, Feld add_domain): domainname not available (vergeben), domainname rules (Name nicht erlaubt), domain limit reached.

del_domain (DELETE)

Löscht eine Domain sofort mit allen Records.

curl -X DELETE "https://ipv64.net/api.php" -H "Authorization: Bearer DEIN_API_KEY" \
  -d "del_domain=deinedomain.ipv64.net"

Erfolg: 202; keine Berechtigung: 403.

DNS-Records anlegen und löschen

add_record (POST)

curl -X POST "https://ipv64.net/api.php" -H "Authorization: Bearer DEIN_API_KEY" \
  -d "add_record=deinedomain.ipv64.net" -d "praefix=nas" -d "type=A" -d "content=192.0.2.20"

Hängst du ?gettoken an die URL (https://ipv64.net/api.php?gettoken), enthält die Antwort zusätzlich record_token – den Record-Token für die Update-URL.

Fehler: 400 mit dns record already there, invalid record informations, domain not found oder record rejected by nameserver.

Let's Encrypt DNS-01: ACME-Clients legen TXT-Records _acme-challenge an. Raten sie die Zone falsch (z. B. add_record=_acme-challenge.example.de bei einer eigenen Domain example.de), setzt die API Domain und Präfix anhand deiner vorhandenen Domains richtig zusammen. Es wird immer die längste passende Domain deines Kontos genommen.

del_record (DELETE)

Löscht einen Record entweder über seine ID (aus get_domains) oder über Domain, Präfix, Typ und Inhalt:

curl -X DELETE "https://ipv64.net/api.php" -H "Authorization: Bearer DEIN_API_KEY" \
  -d "del_record=1234"

curl -X DELETE "https://ipv64.net/api.php" -H "Authorization: Bearer DEIN_API_KEY" \
  -d "del_record=deinedomain.ipv64.net" -d "praefix=_acme-challenge" -d "type=TXT" -d "content=TOKEN_VOM_ACME_CLIENT"

Erfolg: 202; nicht gefunden oder keine Berechtigung: 403.

Healthchecks und Benachrichtigungen

Die Healthchecks samt Benachrichtigungskanälen, Wartungsfenstern und Nodes verwaltest du über die API v2 unter /api/v2/hc2/… – Checks anlegen, ändern, pausieren und löschen, Messwerte und Störungen abfragen. Alle Endpunkte mit curl-Beispielen stehen unter Healthchecks-API.

Für einen Cronjob, der sich nur zurückmelden soll, brauchst du keine API: Ein Push-Check hat eine eigene Push-URL mit seinem Token (siehe Push-Checks).

Außerdem liefert die API v1 mit get_blockers (GET) deine Blocker-Nodes für die v64-Blocklist.

Cloud Router und VPN

Was Cloud Router, Gateways und Peers sind, erklärt die Seite Cloud Router.

API v2

Neben der API v1 gibt es die API v2: eine RESTful JSON-API unter https://ipv64.net/api/v2 für DynDNS, DNS-Records, Healthchecks, DNS Failover, Statusseiten, Offline Pages, CDN64, Cloud Router und DNS64. Die wichtigsten Unterschiede:

• echte Ressourcen-Pfade und HTTP-Methoden (GET, POST, PATCH, DELETE), Bodys als JSON,
• Anmeldung mit denselben API-Keys, aber nur per Header (Authorization: Bearer … oder X-API-Key: …),
• einheitliche Fehler nach RFC 9457 mit Fehlercode, seitenweises Abrufen per Cursor,
• eigene Limits gegen Überlastung, unabhängig vom API-Limit deiner Kontoklasse, mit den Headern RateLimit-Limit und RateLimit-Remaining,
• vollständige Beschreibung als OpenAPI 3.1 zum Import in Postman, Insomnia oder Code-Generatoren.

curl "https://ipv64.net/api/v2/me" -H "Authorization: Bearer DEIN_API_KEY"

Die vollständige Dokumentation mit allen Endpunkten steht unter ipv64.net/api_v2_docs. Die API v1 und die Update-URL bleiben unverändert bestehen.

Fehler gefunden oder etwas fehlt? Schreibt uns im v64.tech-Forum. · Stand: 2026-10-26