Mis à jour le 12 octobre 2026

L’API REST WordPress expose le contenu de votre site en JSON à l’adresse /wp-json/, sans plugin. Elle permet de lire et d’écrire articles, pages et médias depuis N8N, une application mobile ou un front headless, avec une authentification par Application Password et des routes personnalisées via register_rest_route().

Qu’est-ce que l’API REST WordPress et comment la tester ?

C’est une interface HTTP intégrée au cœur de WordPress. Les endpoints de contenu (articles, commentaires, termes, utilisateurs, métadonnées, réglages) sont livrés dans le cœur depuis WordPress 4.7, sorti le 6 décembre 2016. Ouvrez votresite.com/wp-json/ dans un navigateur : vous obtenez l’index de toutes les routes disponibles.

Depuis le début de mon parcours WordPress en 2005, j’ai connu l’époque du XML-RPC. Aujourd’hui, sur les 50 sites et plus que je gère, c’est cette API que j’utilise pour tout ce qui sort du back-office : astuces et usages de l’API REST, automatisations, scripts de contrôle.

Un simple GET suffit pour lister des articles :

GET https://monsite.com/wp-json/wp/v2/posts?per_page=5&_fields=id,title,link,date

Le paramètre _fields limite la réponse aux champs utiles, ce qui allège le JSON. Les contenus publics sont lisibles sans authentification. Les contenus privés, les utilisateurs et les écritures demandent de s’authentifier, comme le précise la documentation officielle.

Comment s’authentifier sur l’API REST WordPress ?

Pour un script ou un outil externe, utilisez un Application Password avec Basic Auth en HTTPS. Pour du code qui tourne dans le navigateur d’un utilisateur connecté, WordPress utilise le cookie de session accompagné d’un nonce X-WP-Nonce. Ce sont les deux méthodes natives, sans plugin.

Les Application Passwords existent depuis WordPress 5.6. Vous les générez sur la page de profil de l’utilisateur, un par application, et vous pouvez les révoquer individuellement. La colonne « dernière utilisation » aide à repérer ceux qui ne servent plus. Par défaut, la fonction n’est disponible que sur un site servi en HTTPS.

curl -X POST https://monsite.com/wp-json/wp/v2/posts 
  -u "utilisateur:abcd efgh ijkl mnop" 
  -H "Content-Type: application/json" 
  -d '{"title": "Article créé via API", "content": "Contenu", "status": "draft"}'

Créez toujours un utilisateur dédié à l’intégration, avec le rôle minimal nécessaire (auteur ou éditeur plutôt qu’administrateur). Si le mot de passe fuit, les dégâts restent limités.

Que faire si l’API répond 401 avec des identifiants corrects ?

Sur certaines configurations serveur (Apache en CGI/FastCGI, parfois LiteSpeed selon la configuration), l’en-tête Authorization n’arrive pas jusqu’à PHP. Un 401 alors que le mot de passe d’application est bon vient très souvent de là. La parade classique, à tester dans le .htaccess :

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Si cela ne change rien, regardez aussi du côté d’un plugin de sécurité ou d’un pare-feu qui bloque l’API REST pour les visiteurs non connectés.

Comment créer ses propres endpoints avec register_rest_route() ?

On déclare une route sur le hook rest_api_init avec un espace de noms, une méthode HTTP, une fonction de rappel et surtout un permission_callback. Les endpoints natifs couvrent la plupart des besoins de lecture et d’écriture de contenu. Les routes personnalisées servent quand il faut agréger des données ou exposer une action métier.

Exemple : les articles d’un auteur, avec leurs champs ACF.

add_action('rest_api_init', function () {
  register_rest_route('mon-api/v1', '/auteur/(?P<id>d+)/posts', [
    'methods'             => 'GET',
    'callback'            => 'recuperer_posts_auteur',
    'permission_callback' => function () {
      return current_user_can('edit_posts');
    },
  ]);
});

function recuperer_posts_auteur(WP_REST_Request $request) {
  $posts = get_posts([
    'author'      => (int) $request['id'],
    'numberposts' => 20,
  ]);

  $resultats = [];
  foreach ($posts as $post) {
    $resultats[] = [
      'id'      => $post->ID,
      'title'   => $post->post_title,
      'excerpt' => get_the_excerpt($post),
      'acf'     => function_exists('get_fields') ? get_fields($post->ID) : [],
    ];
  }
  return rest_ensure_response($resultats);
}

L’expression régulière d+ dans la route n’accepte que des nombres, et le cast (int) sécurise la valeur utilisée ensuite. Depuis WordPress 5.5, omettre le permission_callback déclenche une notice : le cœur vous force à décider explicitement qui peut appeler la route.

Comment sécuriser un endpoint personnalisé ?

Vérifiez les droits de l’appelant dans le permission_callback avec current_user_can(), validez chaque paramètre avec validate_callback ou sanitize_callback, et ne renvoyez jamais plus de données que nécessaire. Ne laissez __return_true que sur une route volontairement publique.

L’erreur que je rencontre le plus souvent en audit : une route d’écriture ou de lecture de données privées déclarée avec 'permission_callback' => '__return_true' pour « faire marcher » le test. Par définition, __return_true rend la route accessible à tout le monde.

  • Données sensibles (e-mails, métadonnées privées, brouillons) : exigez une capacité précise, par exemple edit_posts ou manage_options.
  • Appels depuis le navigateur : le nonce X-WP-Nonce (action wp_rest) est vérifié automatiquement par WordPress pour l’authentification par cookie. Sans nonce valide, la requête est traitée comme celle d’un visiteur anonyme (détails dans la documentation). Inutile de le revérifier à la main dans le callback.
  • Appels machine à machine : Application Password, et rien d’autre à coder.

Quels usages concrets pour l’API REST WordPress ?

Les quatre usages que je rencontre le plus : une application mobile qui lit les articles, une automatisation N8N qui crée du contenu, une synchronisation avec un CRM, et un front headless. Dans chaque cas, l’API standard suffit souvent, sans développement côté WordPress.

Usage Appel typique Authentification
Application mobile (lecture) GET /wp-json/wp/v2/posts Aucune pour le contenu public
Automatisation N8N (création de brouillons) POST /wp-json/wp/v2/posts Application Password
Synchronisation CRM par webhook Route personnalisée en POST Application Password
Front headless (Next.js, Astro) GET au build ou à la demande Aucune en lecture publique

Côté automatisation, mon usage principal est N8N : un workflow lit une source (Google Sheet, formulaire, flux), puis crée ou met à jour un contenu par API. Pour la diffusion sur les réseaux, j’ai détaillé une approche voisine dans publier sur LinkedIn depuis WordPress.

Comment tester ses requêtes avant de coder ?

Testez d’abord la requête dans curl, Postman ou Insomnia, puis seulement après dans votre code ou votre workflow. Le code de retour vous dit presque tout : 201 pour une création réussie, 401 pour un problème d’authentification, 403 pour un manque de droits, 404 pour une route inconnue.

  • Méthode POST sur https://monsite.com/wp-json/wp/v2/posts
  • Authentification Basic Auth : identifiant WordPress et mot de passe d’application
  • En-tête Content-Type: application/json
  • Corps JSON : {"title": "Test", "content": "Contenu", "status": "draft"}

En cas d’erreur 500 sur une route personnalisée, activez WP_DEBUG et WP_DEBUG_LOG dans wp-config.php : l’erreur PHP apparaît dans wp-content/debug.log. Pensez à les désactiver ensuite en production.

Quels plugins aident à exploiter l’API REST ?

Peu de plugins sont nécessaires. Les plus utiles servent à exposer des champs personnalisés ou à gérer des cas d’authentification particuliers. Vérifiez toujours qu’un plugin est maintenu avant de l’installer sur un site de production.

  • ACF : depuis la version 5.11, ACF expose ses champs nativement dans l’API REST. Il faut activer l’option « Show in REST API » sur le groupe de champs. Le plugin « ACF to REST API » n’est donc plus nécessaire dans la plupart des cas.
  • Custom Post Type UI ou votre propre code : un type de contenu n’apparaît dans l’API que si show_in_rest vaut true.
  • Authentification JWT : à réserver aux architectures qui ne peuvent pas utiliser les Application Passwords. C’est plus lourd à maintenir.
  • Cache : si une application interroge l’API en masse, cachez les GET au niveau serveur (LiteSpeed Cache dans mon cas) plutôt que d’ajouter une couche applicative.

API REST ou GraphQL : lequel choisir ?

Partez de l’API REST, qui est native et fonctionne avec curl, N8N, Zapier ou Make sans client spécifique. Passez à GraphQL seulement si un front headless fait de nombreuses requêtes liées et que le sur-chargement de données devient un vrai problème.

GraphQL passe par l’extension WPGraphQL, qui ajoute un schéma et permet de demander exactement les champs voulus en une requête. En contrepartie, il faut maîtriser le schéma, un client dédié et un cache adapté. Pour une application mobile, une intégration CRM ou une automatisation, REST suffit presque toujours.

Où trouver la documentation et comment la mettre à profit ?

La référence est le Handbook de l’API REST sur developer.wordpress.org. Elle liste les endpoints, leurs paramètres et leurs codes de retour. Pour votre propre site, /wp-json/ décrit les routes réellement actives, y compris celles ajoutées par vos plugins.

Ce que cela change dans la pratique : WordPress devient un back-office de contenu que plusieurs fronts peuvent consommer (site, application, tableau de bord). C’est ce qui m’évite de reconstruire un système complet à chaque nouveau besoin d’intégration.

Questions fréquentes

Qu’est-ce que l’API REST de WordPress ?

C’est une interface accessible via /wp-json/ qui expose le contenu du site en JSON. Elle permet de lire et d’écrire articles, pages, médias et métadonnées depuis une application externe, un script ou un outil d’automatisation, sans plugin.

Comment s’authentifier sur l’API REST WordPress ?

Avec un Application Password en Basic Auth sur HTTPS, disponible depuis WordPress 5.6. Il se génère par utilisateur et par application, et se révoque indépendamment sans toucher au mot de passe principal du compte.

Peut-on créer ses propres endpoints ?

Oui, avec register_rest_route() sur le hook rest_api_init. Il faut définir la méthode HTTP, la fonction de rappel et un permission_callback qui contrôle les droits de l’appelant.

L’API REST WordPress est-elle sécurisée ?

Oui si les permissions sont correctes : HTTPS, utilisateur dédié aux droits limités, permission_callback strict et paramètres validés. Le risque vient des routes personnalisées déclarées publiques par erreur.

API REST ou GraphQL ?

REST par défaut, car elle est native et compatible avec tous les outils. GraphQL via WPGraphQL devient utile pour un front headless complexe qui doit limiter le volume de données par requête.