WordPress REST API: complete gids voor endpoints, koppelingen en maatwerk

De WordPress REST API is een interface waarmee WordPress-content en -functionaliteit via URL’s als gestructureerde JSON-data beschikbaar maakt. Daardoor kunnen een externe applicatie, een koppeling of JavaScript-functionaliteit gegevens uit WordPress lezen of, met de juiste rechten, wijzigen. Je gebruikt de API vooral voor integraties en maatwerk, niet voor een gewone bedrijfswebsite zonder externe datastroom of interactieve functionaliteit.

Wat is de WordPress REST API?

Een API is een afgesproken manier waarop systemen gegevens uitwisselen. De REST API van WordPress biedt daarvoor routes en endpoints: specifieke URL’s waarop een applicatie een request doet en een response terugkrijgt.

De response is doorgaans JSON. Dat is een tekstformaat waarin gegevens overzichtelijk als velden en waarden staan. Een applicatie kan die data vervolgens tonen, verwerken of combineren met data uit een ander systeem.

De basis-URL van de WordPress REST API is meestal /wp-json/. Via /wp-json/wp/v2/posts vraag je bijvoorbeeld openbare berichten op. De API is ook een belangrijk technisch onderdeel van de block editor. Voor de inhoudelijke werking van blokken lees je de geplande verdiepende gids over Gutenberg zodra die beschikbaar is; hier ligt de nadruk op de API als verbindingslaag.

Routes, endpoints en HTTP-methodes

Een route is het pad dat een API-functie bereikbaar maakt. Een endpoint is de concrete combinatie van route en toegestane actie. HTTP-methodes geven aan wat je met een resource wilt doen.

• GET: data ophalen, bijvoorbeeld een lijst met pagina’s.
• POST: nieuwe data aanmaken of een actie uitvoeren.
• PUT, PATCH: bestaande data geheel of gedeeltelijk wijzigen.
• DELETE: data verwijderen.

Voor openbare content is een GET-request vaak zonder inloggen mogelijk. Acties die content, instellingen of gegevens van gebruikers wijzigen, vereisen passende authenticatie én toestemming op basis van WordPress-rollen en capabilities.

Belangrijke standaard endpoints in WordPress

WordPress levert standaard endpoints voor veelgebruikte contenttypen. Welke velden beschikbaar zijn, hangt af van het endpoint en van eventuele uitbreidingen door plugins of maatwerk.

Doel	Voorbeeldendpoint	Praktische toepassing	Let op
Berichten ophalen	/wp-json/wp/v2/posts	Nieuwsoverzicht in een externe app of op een ander platform tonen	Beperk de response tot de velden die je werkelijk gebruikt.
Pagina’s ophalen	/wp-json/wp/v2/pages	Pagina-inhoud beschikbaar maken voor een maatwerkfrontend	Controleer vooraf welke pagina’s openbaar mogen zijn.
Media ophalen	/wp-json/wp/v2/media	Afbeeldingen en bijbehorende gegevens ophalen voor een koppeling	Houd rekening met het aantal media-items en de omvang van responses.
Categorieën beheren	/wp-json/wp/v2/categories	Content categoriseren vanuit een gekoppeld systeem	Schrijfacties vragen authenticatie en voldoende rechten.
Custom post type ontsluiten	Een eigen REST-basis binnen /wp-json/wp/v2/	Vacatures, cases, locaties of andere gestructureerde content delen	Het post type moet expliciet voor de REST API zijn ingeschakeld.

Requests slimmer maken met parameters

Een endpoint hoeft niet altijd alle beschikbare data terug te sturen. Queryparameters verfijnen je request. Dat maakt een integratie gerichter en kan voorkomen dat een frontend onnodig veel gegevens moet verwerken.

• ?per_page= beperkt het aantal resultaten per pagina.
• ?page= haalt een volgende resultatenpagina op.
• ?search= zoekt binnen een resource.
• ?_fields= vraagt alleen specifieke velden op.
• ?_embed kan gerelateerde data in de response opnemen.

Gebruik paginering voor grotere collecties. Haal ook niet standaard alle velden op: bepaal per scherm of proces welke gegevens echt nodig zijn. Bij complexe websites spelen performance en onderhoud net zo goed mee als techniek. Een snelle, beheersbare basis begint daarom bij een doordacht strategisch en creatief webdesigntraject.

Authenticatie, rollen en rechten

Authenticatie beantwoordt de vraag wie een request doet. Autorisatie beantwoordt de vraag wat die gebruiker of applicatie mag doen. Beide zijn essentieel zodra een koppeling niet alleen openbare content leest, maar ook data schrijft, verwijdert of afgeschermde informatie opvraagt.

WordPress werkt met rollen en capabilities. Geef een integratie daarom alleen de rechten die nodig zijn voor de specifieke taak. Een koppeling die uitsluitend openbare berichten leest, heeft geen schrijfrechten nodig. Een koppeling die content mag aanmaken, hoeft niet automatisch ook gebruikers of instellingen te kunnen beheren.

Leg vóór de bouw vast welke gegevens toegankelijk zijn, wie eigenaar is van de gebruikte accounts en hoe toegang wordt ingetrokken wanneer een leverancier of medewerker vertrekt. Plaats geheimen en toegangsgegevens nooit in publieke JavaScript-bestanden, een openbare repository of een gedeeld document.

Een custom REST API-endpoint maken

Standaard endpoints zijn voldoende voor veel contentvragen. Een custom endpoint is nuttig wanneer je een bedrijfsproces, berekening of samengestelde dataset veilig beschikbaar wilt maken zonder een externe applicatie direct toegang te geven tot losse WordPress-onderdelen.

Registreer maatwerk bij voorkeur in een eigen plugin, niet in een thema. Zo blijft de functionaliteit los van de vormgeving en beter onderhoudbaar bij een redesign.

add_action( 'rest_api_init', function () {
    register_rest_route( 'mijnbedrijf/v1', '/overzicht', array(
        'methods'             => 'GET',
        'callback'            => 'mijnbedrijf_get_overzicht',
        'permission_callback' => '__return_true',
    ) );
} );

function mijnbedrijf_get_overzicht() {
    return array( 'status' => 'beschikbaar' );
}

Dit is een minimaal technisch voorbeeld van een openbare leesroute. Gebruik __return_true uitsluitend wanneer de data echt openbaar mag zijn. Voor niet-openbare informatie hoort de permission_callback een capability te controleren. Valideer en sanitiseer invoer bij endpoints die parameters of data ontvangen, en definieer duidelijk welke response je teruggeeft.

Custom post types en metadata via de API

Een custom post type helpt om terugkerende bedrijfsinformatie gestructureerd te beheren, zoals vacatures, evenementen, projecten of vestigingen. Wil je die gegevens via de REST API beschikbaar maken, dan moet dat bij de registratie van het post type expliciet zijn toegestaan. Ook custom velden en metadata hebben een bewuste registratie en toegangscontrole nodig voordat je ze veilig via de API deelt.

Dat is een belangrijk ontwerpbesluit: maak niet alle interne velden automatisch openbaar. Bepaal per veld of het bedoeld is voor publieke weergave, intern beheer of een beperkte integratie.

Wanneer gebruik je de WordPress REST API?

Situatie	REST API nodig?	Logische aanpak
Een reguliere zakelijke website met pagina’s, formulieren en blogartikelen	Meestal niet als apart project	Gebruik WordPress regulier; de API blijft op de achtergrond beschikbaar voor WordPress-functionaliteit.
Content tonen in een externe app, portaal of scherm	Vaak wel	Gebruik standaard endpoints en beperk velden, content en rechten.
Data uit een CRM, planningstool of ander systeem tonen of verwerken	Vaak wel	Ontwerp een afgebakende koppeling met eigenaar, foutafhandeling en toegangsbeleid.
Een volledig losse JavaScript-frontend op WordPress-data	Ja, als onderdeel van de architectuur	Onderzoek eerst de afwegingen van headless WordPress, waaronder preview, beheer en onderhoud.
Eén simpele, unieke bewerking zonder hergebruik	Niet altijd	Beoordeel of reguliere WordPress-functionaliteit of server-side maatwerk eenvoudiger is.

Een REST API is dus geen doel op zichzelf. Kies ervoor als systemen of interfaces gegevens herbruikbaar en gecontroleerd moeten uitwisselen. Voor een volledig ontkoppelde frontend is de API slechts één onderdeel van de oplossing. De gekozen architectuur moet passen bij beheerbaarheid, contentworkflow en commerciële doelen van de website.

Veelvoorkomende fouten oplossen: 401, 403 en 404

• 401 Unauthorized: de request bevat geen geldige authenticatie voor een afgeschermde actie. Controleer hoe de applicatie zich identificeert.
• 403 Forbidden: de identiteit is bekend, maar beschikt niet over de vereiste capability. Controleer rol, rechten en de permission callback.
• 404 Not Found: de route bestaat niet, het endpoint is verkeerd geschreven of de relevante functionaliteit is niet geregistreerd.

Test eerst de basis-URL /wp-json/, daarna de exacte route en pas vervolgens de parameters toe. Controleer ook of een beveiligingsplugin, cachinglaag of serverregel requests beïnvloedt. Voor gewone webpagina’s geldt hetzelfde uitgangspunt: een ontbrekende URL vraagt om een bewuste oplossing. Lees hoe je 404- en soft-404-fouten oplost als je daarnaast problemen met indexeerbare pagina’s onderzoekt.

Implementatie in 6 stappen

1. Beschrijf het bedrijfsdoel. Formuleer welke data van welk systeem naar welk systeem moet en waarom. Vermijd een API-project omdat het technisch interessant klinkt.
2. Maak een datalijst. Noteer per veld de bron, eigenaar, gevoeligheid, gewenste richting en frequentie van gebruik. Scheid openbare, interne en vertrouwelijke gegevens.
3. Kies standaard of maatwerk. Controleer eerst of bestaande WordPress-endpoints en beschikbare velden voldoen. Bouw alleen een custom route voor een concrete, ontbrekende functie.
4. Ontwerp rechten per actie. Bepaal wie alleen mag lezen, wie mag schrijven en welke capability daarvoor vereist is. Geef nooit ruimere toegang dan nodig.
5. Bouw en test buiten productie. Test normale requests, ongeldige invoer, ontbrekende rechten, lege resultaten en foutmeldingen voordat de koppeling live gaat.
6. Leg beheer vast. Documenteer routes, velden, verantwoordelijken, foutmeldingen en wijzigingsproces. Controleer na WordPress-, plugin- of integratiewijzigingen of de koppeling nog werkt.

Beveiliging, performance en onderhoud

Beveiliging begint met minimale toegang. Publiceer alleen data die publiek mag zijn, valideer invoer aan de serverkant en controleer permissions voor elke afgeschermde actie. Een custom endpoint verdient dezelfde code review en onderhoudsdiscipline als andere maatwerkfunctionaliteit.

Voor performance geldt: beperk resultaten, velden en onnodige gerelateerde data. Analyseer eerst welke requests een frontend werkelijk doet. Voeg caching pas toe met duidelijke regels voor verversing, zodat bezoekers geen verouderde bedrijfsinformatie zien.

Plan ook onderhoud in. De API is afhankelijk van WordPress-core, plugins, themafunctionaliteit, serverinstellingen en externe systemen. Een update aan één kant kan een aanname in de koppeling veranderen. Houd daarom technische documentatie, foutlogging en een testprocedure beschikbaar.

Praktische checklist voor je API-project

• Het bedrijfsdoel en de eigenaar van de koppeling zijn vastgelegd.
• Per endpoint is duidelijk welke data gelezen of gewijzigd wordt.
• Openbare en afgeschermde data zijn van elkaar gescheiden.
• Rollen, capabilities en permission callbacks zijn per actie beoordeeld.
• Invoer wordt gevalideerd en gesanitiseerd.
• Requests gebruiken alleen noodzakelijke velden en resultaten.
• Fouten, logging en beheer na livegang zijn geregeld.
• De technische keuze past bij de gewenste website- en contentstrategie.

Hulp bij WordPress-maatwerk en koppelingen

Een goede API-koppeling begint met heldere requirements en een websitearchitectuur die aansluit op je processen. LYNX Media combineert webdesign, WordPress-development en online groeivragen binnen een samenhangende aanpak. Bekijk de diensten van LYNX Media of bespreek je website of online groeikansen met LYNX Media.