Die WordPress REST API: Was sie ist und wie man sie verwendet

Tu WordPress no es solo una web: también es un servidor de datos. Desde la versión 4.7, la REST API de WordPress viene integrada en el núcleo y expone entradas, páginas, usuarios, medios y taxonomías en formato JSON, listos para ser leídos o modificados desde cualquier aplicación externa: una app móvil, un script de automatización, otra web o un panel de control a medida. Es la tecnología que hace funcionar el editor de bloques, la que usan miles de integraciones y la puerta de entrada al llamado WordPress «headless». Y, sin embargo, muchos usuarios avanzados no la han explorado nunca. En esta guía práctica veremos qué es exactamente la REST API de WordPress, cómo están organizados sus endpoints, cómo autenticarte de forma segura con Application Passwords, cómo leer y crear contenido con ejemplos reales (desde el navegador, con JavaScript y con PHP), cómo crear tus propios endpoints y qué precauciones de seguridad conviene tomar. Todo con código funcional que puedes probar hoy en tu propia web.

Qué es la REST API de WordPress y para qué sirve

Una API REST es una interfaz que permite a dos sistemas comunicarse sobre HTTP usando las operaciones clásicas del protocolo: GET para leer, POST para crear, PUT/PATCH para actualizar y DELETE para borrar. La respuesta llega en JSON, un formato de texto ligero que cualquier lenguaje entiende. En el caso de WordPress, eso significa que todo lo que gestionas desde el escritorio (entradas, páginas, comentarios, categorías, usuarios, medios) tiene también una «puerta trasera» estructurada y oficial para máquinas.

Casos de uso reales donde la REST API de WordPress marca la diferencia:

• Automatización: publicar o actualizar contenido desde scripts, hojas de cálculo o herramientas como n8n y Make.
• Headless WordPress: WordPress nur als Content-Manager nutzen und das Frontend mit React, Vue oder Astro aufbauen.
• Mobile Apps: die offizielle WordPress-App funktioniert vollständig über diese API.
• Integrationen zwischen Websites: die neuesten Artikel einer anderen Website anzeigen, Kataloge synchronisieren, die Veröffentlichung zentralisieren.
• Maßgeschneiderte Dashboards: Dashboards, die in WordPress lesen und schreiben, ohne wp-admin zu verwenden.

Die API ist auch die Grundlage für moderne Integrationen mit künstlicher Intelligenz: Plugins wie AI Engine, das dein WordPress in einen KI-Agenten verwandelt, stützen sich darauf, um Inhalte externen Assistenten zugänglich zu machen.

Haupt-Endpoints: Die API-Karte

Alles beginnt mit einer URL: https://tudominio.com/wp-json/. Öffne sie im Browser und du siehst den vollständigen Index der verfügbaren Routen. Die Core-Endpoints hängen vom Namensraum ab wp/v2:

Jeder Sammlungs-Endpoint unterstützt sehr nützliche Abfrageparameter: ?per_page=5 begrenzt Ergebnisse, ?search=wordpress sucht, ?categories=12 filtert nach Kategorie, ?orderby=date&order=asc sortiert und ?_fields=id,title,link gibt nur die von dir angeforderten Felder zurück und entlastet so die Antwort. Für ein bestimmtes Element wird dessen ID hinzugefügt: /wp-json/wp/v2/posts/123.

Die JSON-Antworten von WordPress kommen unformatiert, in einer einzigen, schwer lesbaren Zeile. Ein Workflow-Tipp: Füge die Antwort in unseren ein kostenloser JSON-Formatierer und -Validator und du erhältst den eingerückten und farbigen Baum, um ihn bequem zu inspizieren.

Paginierung: Die Header, die du kennen solltest

Sammlungs-Endpoints geben maximal 100 Elemente pro Anfrage zurück (standardmäßig 10). Um große Kataloge zu durchlaufen, enthält die API in jeder Antwort zwei HTTP-Header: X-WP-Total, mit der Gesamtzahl der Elemente, und X-WP-TotalPages, mit der Anzahl der verfügbaren Seiten gemäß deiner per_page. Es genügt, durch Hinzufügen von zu iterieren ?page=2, ?page=3 und so weiter, bis die letzte erreicht ist. Wenn du eine nicht existierende Seite anforderst, antwortet die API mit einem 400-Fehler mit dem Code rest_post_invalid_page_number, ein praktisches Signal, um die Schleife in Export- oder Migrationsskripten zu stoppen.

Authentifizierung mit Anwendungspasswörtern

Das Lesen öffentlicher Inhalte erfordert keine Authentifizierung, aber das Erstellen, Bearbeiten oder Löschen schon. Seit WordPress 5.6 sind die integrierte und empfohlene Methode die Anwendungspasswörter (Anwendungspasswörter): anwendungsspezifische Schlüssel, die einzeln widerrufbar sind und dein echtes Passwort nicht preisgeben.

Um eine zu erstellen: gehe zu Benutzer → Profil, scrolle nach unten zu „Anwendungspasswörter“, gib einen beschreibenden Namen ein (z.B. „Veröffentlichungsskript“) und klicke auf Erstellen. WordPress zeigt dir einmalig einen Schlüssel im Format xxxx xxxx xxxx xxxx xxxx xxxx. Speichere es in einem Passwortmanager oder in einer Umgebungsvariablendatei, niemals im Quellcode.

Der Schlüssel wird mit HTTP Basic Authentifizierung verwendet: Benutzername und Anwendungspasswort Base64-kodiert im Header Authorization. Eine wesentliche Voraussetzung: Die Website muss über HTTPS bereitgestellt werden, da bei einfachem HTTP die Anmeldeinformationen ungeschützt übertragen würden.

Schnelltest vom Terminal mit curl:

curl -X POST https://tudominio.com/wp-json/wp/v2/posts \
  -u "tu_usuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{"title":"Borrador desde la API","status":"draft"}'

Wenn die Antwort ein JSON mit der ID des neuen Entwurfs ist, funktioniert die Authentifizierung. Jede Berechtigung hängt von der Benutzerrolle ab: Ein Anwendungspasswort eines Abonnenten kann keine Beiträge veröffentlichen.

Inhalte lesen und erstellen: Beispiele mit JavaScript

Sehen wir uns die API in Aktion an mit fetch, genau wie du es auf einer externen Website oder

const API = 'https://tudominio.com/wp-json/wp/v2';

async function ultimasEntradas() {
  const res = await fetch(`${API}/posts?per_page=5&_fields=id,title,link,date`);
  if (!res.ok) {
    throw new Error('Error HTTP ' + res.status);
  }
  const posts = await res.json();
  posts.forEach((post) => {
    console.log(`${post.date} — ${post.title.rendered} — ${post.link}`);
  });
}

ultimasEntradas();

Und jetzt, einen Beitrag erstellen, indem wir uns mit einem Anwendungspasswort authentifizieren (dies muss in einer Serverumgebung oder einem privaten Skript ausgeführt werden, niemals im Browser deiner Besucher, da es den Schlüssel offenlegen würde):

const usuario = 'tu_usuario';
const clave   = 'xxxx xxxx xxxx xxxx xxxx xxxx';
const token   = Buffer.from(`${usuario}:${clave}`).toString('base64');

async function crearEntrada() {
  const res = await fetch('https://tudominio.com/wp-json/wp/v2/posts', {
    method: 'POST',
    headers: {
      'Authorization': `Basic ${token}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      title: 'Publicado por la REST API',
      content: '<p>Este contenido lo ha creado un script.</p>',
      status: 'draft',
      categories: [12],
    }),
  });
  const data = await res.json();
  if (!res.ok) {
    throw new Error(data.message || 'Error al crear la entrada');
  }
  console.log('Creada con ID', data.id, '→', data.link);
}

crearEntrada();

Beachte das Detail von title.rendered beim Lesen: Die API gibt die Textfelder als Objekte mit den Varianten zurück rendered (finales HTML) und, wenn du mit Bearbeitungsberechtigungen authentifiziert bist und ?context=edit, auch raw (Originalinhalt).

Eigene Endpunkte mit register_rest_route erstellen

Die Core-API deckt Standardinhalte ab, aber das wahre Potenzial entfaltet sich, wenn du eigene Daten bereitstellst. Mit register_rest_route() kannst du benutzerdefinierte Routen unter deinem eigenen Namensraum erstellen. Vollständiges Beispiel: ein Endpunkt, der grundlegende Website-Statistiken zurückgibt, mit einem validierten Parameter und Berechtigungsprüfung:

<?php
add_action( 'rest_api_init', function () {
    register_rest_route( 'biblioweb/v1', '/estadisticas', array(
        'methods'             => 'GET',
        'callback'            => 'biblioweb_api_estadisticas',
        'permission_callback' => '__return_true', // Endpoint público de solo lectura.
        'args'                => array(
            'tipo' => array(
                'default'           => 'post',
                'sanitize_callback' => 'sanitize_key',
                'validate_callback' => function ( $valor ) {
                    return post_type_exists( $valor );
                },
            ),
        ),
    ) );
} );

function biblioweb_api_estadisticas( WP_REST_Request $request ) {
    $tipo     = $request->get_param( 'tipo' );
    $conteo   = wp_count_posts( $tipo );
    $usuarios = count_users();

    return rest_ensure_response( array(
        'tipo'        => $tipo,
        'publicados'  => (int) $conteo->publish,
        'borradores'  => (int) $conteo->draft,
        'usuarios'    => (int) $usuarios['total_users'],
        'generado_en' => current_time( 'mysql' ),
    ) );
}

Nach dem Speichern dieses Codes (in einem Plugin oder Snippet) antwortet dein neuer Endpunkt unter https://tudominio.com/wp-json/biblioweb/v1/estadisticas?tipo=page. Drei goldene Regeln: Verwende immer einen eigenen, versionierten Namensraum (biblioweb/v1), definiere permission_callback explizit (ist seit WordPress 5.5 obligatorisch; für private Endpunkte verwende eine Überprüfung wie current_user_can( 'edit_posts' )) und validiert jeden Eingabeparameter. Die vollständige Referenz befindet sich im offizielles Handbuch der WordPress REST-API.

Sicherheit: Was offenzulegen und was zu schützen ist

Die WordPress REST-API ist von Haus aus sicher (sie legt nur offen, was bereits öffentlich ist und erfordert Berechtigungen zum Schreiben), aber es ist ratsam, einige Details anzupassen:

• Benutzeraufzählung: der Endpunkt /wp/v2/users listet Autoren mit veröffentlichten Inhalten auf, was einem Angreifer erleichtert, gültige Benutzernamen zu erfahren. Viele Sicherheits-Plugins schränken dies ein; es kann auch per Code gefiltert werden, um Authentifizierung zu erfordern.
• HTTPS obligatorisch: Ohne SSL-Zertifikat werden die Anwendungspasswörter im Klartext übertragen. Es gibt keine vernünftige Ausnahme von dieser Regel.
• Prinzip der geringsten Rechte: Erstelle die Anwendungspasswörter mit einem Benutzer, dessen Rolle nur die Berechtigungen hat, die die Integration benötigt, und widerrufe sie, wenn sie nicht mehr verwendet werden.
• Deaktiviere die API nicht blindlings: der Block-Editor und viele Plugins hängen von ihr ab. Wenn du sie einschränken möchtest, erzwinge Authentifizierung mit dem Filter rest_authentication_errors anstatt sie komplett zu blockieren.
• Begrenze die Angriffsfläche: Öffentliche benutzerdefinierte Endpunkte sollten nur Daten zurückgeben, bei denen es dir nichts ausmacht, dass sie für jedermann sichtbar sind.

Diese Vorsichtsmaßnahmen passen in eine allgemeine Härtungsstrategie; wenn du sie überprüfen möchtest, haben wir einen Leitfaden mit Tricks zur Stärkung der Sicherheit Ihres WordPress.

Häufig gestellte Fragen

Ist die WordPress REST-API auf meiner Website aktiv?

Mit ziemlicher Sicherheit ja: Sie ist seit WordPress 4.7 (2016) standardmäßig aktiviert. Überprüfe es, indem du tudominio.com/wp-json/: Wenn du ein JSON mit dem Namen deiner Website und der Liste der Routen siehst, ist sie betriebsbereit. Wenn sie einen 404 zurückgibt, überprüfe die Permalinks oder ein Sicherheits-Plugin, das sie blockiert.

Ist es gefährlich, die API aktiviert zu haben?

Nicht mehr als die Veröffentlichung der Website. Die Lese-API legt nur Inhalte offen, die auf deiner Website bereits öffentlich sind, und jeder Schreibvorgang erfordert Authentifizierung und Berechtigungen. Die beiden sinnvollen Einstellungen sind, die Benutzerliste einzuschränken und sicherzustellen, dass alles über HTTPS bereitgestellt wird. Sie komplett zu deaktivieren, verursacht oft mehr Probleme, als es vermeidet.

Kann ich die API mit benutzerdefinierten Beitragstypen und benutzerdefinierten Feldern verwenden?

Ja. Benutzerdefinierte Beitragstypen erscheinen in der API, wenn sie mit show_in_rest => true, und erhalten ihren eigenen Endpunkt (zum Beispiel /wp/v2/proyecto). Benutzerdefinierte Felder werden mit register_post_meta() ebenfalls markieren show_in_rest, oder mit dem Feld meta des Beitrags selbst, wenn das Plugin, das sie erstellt, dies unterstützt.

Welchen Unterschied gibt es zwischen der REST-API und WPGraphQL?

Die REST-API ist der Core-Standard: Jeder Datentyp hat seinen Endpunkt und die Antworten haben eine feste Struktur. GraphQL (über das WPGraphQL-Plugin) ermöglicht es, genau die benötigten Felder in einer einzigen Abfrage anzufordern, was bei komplexen Headless-Projekten beliebt ist. Für Automatisierungen, Integrationen und die meisten Projekte ist die REST-API einfacher, erfordert keine Plugins und wird offiziell unterstützt.

Es ist ratsam, mindestens einmal pro Quartal ein vollständiges SEO-Audit durchzuführen. Sie sollten jedoch die Leistung Ihrer Keywords und den Zustand Ihrer Website wöchentlich überwachen. Inhaltsaktualisierungen und kleinere Optimierungen können regelmäßiger vorgenommen werden.

Die WordPress REST-API verwandelt deine Website in eine programmierbare Plattform: ein klares Verzeichnis von Endpunkten unter /wp-json/wp/v2/, integrierte Authentifizierung mit Anwendungspasswörtern über HTTPS und die Möglichkeit, die Karte mit eigenen Routen mittels zu erweitern. register_rest_route(). Mit dem, was in diesem Leitfaden gezeigt wurde, kannst du öffentliche Inhalte von jeder Anwendung aus lesen, mittels authentifizierter Skripte veröffentlichen und bearbeiten, benutzerdefinierte Daten mit Validierung und Berechtigungen bereitstellen und dies mit den entsprechenden Sicherheitsvorkehrungen tun. Der beste Weg, sie zu verinnerlichen, ist praktisch: Öffne tudominio.com/wp-json/wp/v2/posts?per_page=3 im Browser die Antwort durch einen JSON-Formatierer leiten, um ihre Struktur zu verstehen, dein erstes Anwendungspasswort erstellen und einen Entwurf mit curl senden. In fünfzehn Minuten hast du die Tür durchschritten, die die Nutzung von WordPress vom Programmieren mit WordPress trennt.