WordPress REST API: Vollständiger Guide für Entwickler

Die WordPress REST API ermöglicht es dir, mit WordPress über HTTP-Anfragen und JSON zu arbeiten, statt über die üblichen wp-admin-Ansichten. Mit der WordPress REST API kannst du Inhalte aus JavaScript-Apps, mobilen Apps, anderen Backends oder sogar Automatisierungsskripten konsistent abrufen und aktualisieren.

In diesem Guide lernst du, was die WP REST API ist, wie die Endpunkte strukturiert sind und wie du sie nutzt, um echte Integrationen und Headless-Websites aufzubauen.

Im Kern macht die WordPress REST API die Daten deiner Website – Beiträge, Seiten, Benutzer, Taxonomien, Custom Post Types – über HTTP mittels JSON-Payloads verfügbar. Statt eine HTML-Seite zu rendern, kann WordPress mit strukturiertem JSON antworten, das jeder Client parsen kann. Deshalb sind die Endpunkte ein Grundpfeiler von Headless- und entkoppelten Architekturen.

WordPress wird mit Standard-Endpunkten unter dem Namensraum /wp-json/wp/v2/ ausgeliefert, die Dinge wie das Auflisten oder Erstellen von Beiträgen erledigen. Wenn ein Client einen dieser Endpunkte aufruft, fährt WordPress seinen Kern hoch, leitet die Anfrage durch die API-Infrastruktur und gibt JSON statt HTML zurück.

Zum Beispiel nutzt ein einfacher GET-Request an /wp-json/wp/v2/posts das integrierte Routing, um eine Liste von Beiträgen zurückzugeben – egal ob aus einer React-App, einer mobilen App oder einem serverseitigen Skript. Unter der Haube gelten die gleichen Berechtigungsprüfungen, sodass authentifizierte Aufrufe auch Entwürfe sehen, während anonyme Aufrufe nur veröffentlichte Inhalte sehen.

Die API basiert auf ein paar Kernkonzepten, die dir in jedem Beispiel begegnen werden.

• Routen sind URL-Muster wie /wp-json/wp/v2/posts, die auf die Logik innerhalb von WordPress gemappt werden.
• Endpunkte sind die Kombi aus einer Route und einer HTTP-Methode, wie GET oder POST auf /wp-json/wp/v2/posts.
• JSON ist das Datenformat für Requests und Responses – oft als WordPress-JSON-API-Layer bezeichnet, da es den Datenaustausch standardisiert.

Sobald du diese Basics verstanden hast, geht es in den meisten Tutorials nur noch darum, CRUD-Operationen den richtigen Routen und Methoden zuzuordnen.

Bevor du Endpunkte per Code ansprichst, solltest du prüfen, ob die API aktiv ist, die Basic-Auth konfigurieren und einen Weg finden, Aufrufe lokal zu testen.

Die wichtigsten Voraussetzungen sind:

• Eine halbwegs aktuelle WordPress-Installation.
• Funktionierende Permalinks.
• Das Wissen darüber, was öffentlich sichtbar ist und was hinter einer Authentifizierung liegt.

Bei modernen WordPress-Installationen ist das Aktivieren meist nur ein „Checken, ob es läuft“, statt wirklich einen Schalter umzulegen. Besuch /wp-json/ im Browser; wenn du einen JSON-Index mit Namensräumen und Routen siehst, ist die REST API aktiv und startklar.

Falls der Request fehlschlägt, check Folgendes:

• Sicherheits-Plugins, die den REST-Zugriff blockieren.
• Eigene .htaccess Regeln, die /wp-json/ oder wp-json.php verbieten.
• Firewalls auf Hosting-Ebene, die diese Pfade blockieren.

Sobald der Index lädt, kannst du in spezifische Namensräume klicken oder Tools wie Postman nutzen, was beim lokalen Testen eines Plugins super praktisch ist.

Für alles, was über öffentliche Inhalte hinausgeht, brauchst du eine WordPress REST API-Authentifizierung. Die einfachsten Optionen für lokale Tests sind:

• Ein Plugin für Basic-Auth (Authentifizierung) oder JWT (nur für Dev- oder Staging-Umgebungen gedacht).
• Die integrierte Cookie-Authentifizierung, wenn du aus einer angemeldeten Browser-Session testest.

In der Produktion solltest du Anmeldedaten nie hart im Client codieren und genauer bei der Methodenwahl sein, aber für frühe Experimente reicht ein Plugin-basierter Auth-Layer meist aus.

Sobald die Auth steht, teste die Basics mit cURL, damit du nicht raten musst. Um zum Beispiel das Abrufen von Beiträgen zu testen, kannst du das hier ausführen:

curl https://example.com/wp-json/wp/v2/posts

Für Beispiele, die Auth erfordern, fügst du einfach Header oder Credentials hinzu, je nachdem, welche Methode du gewählt hast. So kannst du auch einen Custom Endpoint testen, indem du die Route ansteuerst, bevor du Client-Code schreibst, und sicherstellen, dass nach Plugin-Änderungen noch alles läuft.

Sobald deine Umgebung steht, kannst du anfangen, strukturiert gegen die WordPress REST API zu entwickeln. Typische Abläufe beinhalten das Auflisten von Inhalten, das Erstellen, Bearbeiten und Löschen von Ressourcen – oft kombiniert mit der WordPress REST API Pagination.

Für Leseoperationen nutzt du GET-Endpunkte wie GET /wp-json/wp/v2/posts oder GET /wp-json/wp/v2/pages. Diese GET-Anfragen beachten die Berechtigungen: Öffentliche Clients sehen nur öffentliche Daten, während authentifizierte Clients auch private Inhalte oder Entwürfe sehen.

Du kannst die Abfragen mit Parametern wie ?per_page=10&page=2 oder Filtern für Kategorien verfeinern. Die Header verraten dir, wie viele Seiten es gibt, damit dein Client „Load More“ oder Infinite Scroll ohne Raten bauen kann.

Um Beiträge oder andere Ressourcen zu erstellen, sendest du JSON-Payloads per POST an den entsprechenden Endpunkt. Zum Beispiel erlaubt ein POST-Request an /wp-json/wp/v2/posts mit Feldern für Titel, Inhalt und Status, Inhalte direkt aus dem Code heraus zu veröffentlichen oder als Entwurf zu speichern.

Da diese Operationen Daten ändern, erfordern sie eine WordPress REST API Authentifizierung und die passenden Rechte – du solltest sie also nicht für anonyme Clients freigeben. Oft kombinierst du das trotzdem mit Pagination, wenn der Client danach Listen der neu erstellten Elemente abrufen muss.

Zum Bearbeiten nutzt du PUT oder PATCH, um aktualisierte Daten an eine bestehende Ressource zu senden. Ein typischer REST-API-Aufruf wäre PUT /wp-json/wp/v2/posts/123 mit einem JSON-Body, der nur die Felder enthält, die du ändern willst.

Um Beiträge oder Ressourcen zu entfernen, nutzt du DELETE am passenden Endpunkt. Zum Beispiel sagt DELETE /wp-json/wp/v2/posts/123 der API, dass ein Beitrag in den Papierkorb verschoben oder (je nach Argumenten) permanent gelöscht werden soll.

Da diese Operationen destruktiv sind, solltest du über extra Schutz wie Rollen-Checks oder Rate-Limiting nachdenken, besonders bei Admin-Tools, die Massenlöschungen erlauben.

Die Standard-Endpunkte decken vieles ab, aber oft brauchst du eigene Logik für Business-Rules, externe Datenflüsse oder maßgeschneiderte Antworten. Genau hier kommt der Support für Custom Endpoints der WordPress REST API ins Spiel.

Überleg dir, einen Custom Endpoint hinzuzufügen, wenn:

• Du einen speziellen Datensatz freigeben willst, der nicht sauber in die bestehenden Sammlungen passt.
• Du eigene Berechnungen anstellen oder mehrere Abfragen kombinieren musst, bevor du das JSON zurückgibst.
• Du ein saubereres Interface für externe Nutzer willst als die Standard-Routen der WordPress REST API.

Das ist besonders oft der Fall bei Dashboards, Apps oder Integrationen, die die internen WordPress-Abläufe gar nicht kennen müssen.

Eigene Routen registrierst du über register_rest_route in deinem Plugin oder Theme. Du gibst einen Namespace, ein Routen-Muster, erlaubte HTTP-Methoden und einen Callback an, wodurch ein neuer Custom Endpoint unter deinem Pfad erreichbar wird.

Zum Beispiel könntest du /wp-json/myplugin/v1/report registrieren, um Statistiken zurückzugeben, die intern zwar Standard-Endpunkte nutzen, aber als eine optimierte Antwort geliefert werden.

Der Callback, den du registrierst, verarbeitet den Request, führt deine Logik aus und gibt die Daten zurück. Behandle diese Funktionen wie jede andere öffentliche API: Validier den Input, check die Berechtigungen und schütz dich vor Missbrauch.

Nutze Authentifizierungs-Checks in deinen Permission-Callbacks und setz auf Security-Features wie Nonces, Capability-Checks und Rate-Limiting, wo es Sinn macht. Sensible Endpunkte sollten immer den User verifizieren und brauchen eventuell ein Nonce-Token, um das CSRF-Risiko zu senken.

Die Authentifizierung regelt, wer was über die API machen darf – das ist entscheidend für die Sicherheit und die UX. Welche Methode du wählst, hängt von deiner Umgebung, dem Client-Typ und deinen Sicherheitsanforderungen ab.

Cookie-basierte Auth nutzt WordPress für eingeloggte User im Admin-Bereich. Wenn ein Browser eingeloggt ist, kannst du dank der Cookie-Authentifizierung Endpunkte per JavaScript auf derselben Domain ohne extra Header aufrufen.

Das ist praktisch für Admin-Tools und interne Dashboards, aber nichts für Apps von Drittanbietern oder Cross-Domain-Clients – genau da kommen dann andere Methoden ins Spiel.

Für externe Clients und Multi-Tenant-Systeme passt OAuth 2.0 oft besser. Mit einem OAuth-Flow geben User über Token begrenzten Zugriff auf die API frei, ohne ihr Passwort zu teilen – ganz nach den Security Best Practices.

Meist nutzt du ein Plugin oder Gateway für OAuth-Support und konfigurierst Scopes und Token-Laufzeiten passend zu den Daten, die deine Clients brauchen.

Modernes WordPress unterstützt auch Anwendungspasswörter – das sind lange, zufällige Zugangsdaten, die du pro User und Client generierst. Die funktionieren super für Server-zu-Server-Automatisierung, wo ein kompletter interaktiver Login zu viel des Guten wäre.

Da Anwendungspasswörter direkt in die Authentifizierung und Sicherheit integriert sind, lassen sie sich oft leichter verwalten als ein eigenes Token-System, besonders bei kleinen Skripten oder CI-Jobs.

Sobald du mit den Basics klarkommst, fallen die häufigsten Muster in drei Kategorien: Headless-Builds, Integrationen und Automatisierung.

In einem Headless-Setup fungiert WordPress als Content-Backend, während ein separates Frontend (React, Vue, Svelte, Static Site Generator) Daten über die API abruft. Deshalb sind Headless-CMS-Architekturen so beliebt: Sie bieten das vertraute Redaktions-Erlebnis und geben Developern gleichzeitig volle Freiheit beim Frontend.

Du kannst den Headless-Client hosten, wo du willst, und ihn über HTTPS mit der API kommunizieren lassen; diese Entkopplung macht es auch leichter, den Traffic unabhängig vom Admin-Bereich zu skalieren.

Die Integration ist mit der REST API viel sauberer als mit altem XML-RPC oder irgendwelchen Custom Endpoints. Du kannst CRMs, Marketing-Tools oder interne Systeme anweisen, Inhalte über authentifizierte Requests zu erstellen oder Daten aus anderen Diensten in WordPress zu spiegeln.

Wenn du so eine Integration baust, nutz die Muster aus der Doku und halt dich an ein klares JSON-Schema, damit beide Seiten langfristig wartbar bleiben.

WooCommerce hat eigene Endpunkte, aber viele Teams nutzen auch die Core-API für ihre Workflows. Zum Beispiel könnte deine WordPress-API-Integration:

• Landing-Pages für neue Produkte automatisch generieren.
• Bestell- oder Kundendaten mit externen Tools synchronisieren.
• Einen Post-Trigger auslösen, um Content zu erstellen, sobald sich ein Status ändert.

Da Automatisierungscode oft lange läuft, solltest du Auth, Permissions und Error-Handling von Anfang an sauber halten.

Sobald du API-Features veröffentlichst, brauchst du ein paar Guardrails für Security, Validierung, Caching und Performance. Diese Security- und Stabilitäts-Checks sparen dir später eine Menge Debugging.

Behandle jeden Endpunkt als potenzielle Angriffsfläche. Nutze Security-Features der WordPress REST API wie:

• Capability-Checks (current_user_can) in den Permission-Callbacks.
• Nonces für sensible Vorgänge nutzen – verwende den Nonce-Mechanismus einfach überall dort, wo es angebracht ist.
• HTTPS überall, besonders für authentifizierte Aufrufe.

Wenn ein Endpunkt nicht öffentlich sein muss, sicher ihn per Auth ab, statt dich auf „Security by Obscurity“ zu verlassen.

Input-Handling ist genauso wichtig wie Auth. Wann immer du Daten annimmst, bereinige und validiere sie mit WordPress-Helpern und strikten Schemas. Das ist ein Kernteil der API-Security und verhindert XSS, SQL-Injections und andere Probleme, die über JSON-Payloads reinkommen könnten.

Caching sorgt dafür, dass deine API auch unter Last schnell antwortet. Du kannst Antworten auf mehreren Ebenen cachen:

• Im Client über Standard-HTTP-Header.
• In WordPress, indem du Ergebnisse in Transients oder im Object-Cache speicherst.
• Am Edge mit einem CDN vor den öffentlichen WordPress-REST-API-Endpunkten.

Für viel Traffic hilft die Kombi aus WordPress-Caching und stabiler Infrastruktur (z. B. die App auf einem VPS mit genug CPU und RAM statt auf Shared Hosting zu betreiben), damit die API auch bei Spikes stabil bleibt.

Behalt das Nutzungsverhalten im Auge und füg Rate-Limiting hinzu, wo es Sinn macht. Einfache Dinge wie das Blocken von missbräuchlichen Clients, Pagination für große Listen und das Auslagern schwerer Abfragen bringen extrem viel.

Infrastrukturell gesehen bietet dir performantes Hosting – wie ein Contabo VPS oder eine ähnliche Umgebung mit dedizierten Ressourcen – mehr Spielraum für API-Traffic als billige Shared-Tarife. Das, kombiniert mit durchdachtem Endpunkt-Design, sorgt dafür, dass die Arbeit mit der API auch bei wachsender App angenehm bleibt.