WordPress REST API i praksis: hent og opdatér data udefra

Kort svar: WordPress’ REST API gør sitets indhold tilgængeligt som data på faste adresser under /wp-json/: indlæg, sider, medier, kategorier – og med WooCommerce også produkter og ordrer. Læsning af offentligt indhold kræver ingen nøgle (prøv /wp-json/wp/v2/posts i browseren); skrivning kræver autentificering – nemmest med et applikationskodeord på en dedikeret bruger med mindst nødvendige rolle. Det er API’et, der driver integrationsplatforme, apps og headless-løsninger, og med to små øvelser i denne guide forstår du, hvordan automatiseringsværktøjer taler med dit site.

Fagligt gennemgået: 2. oktober 2026

REST API’et er WordPress’ officielle indgang for andre systemer: en struktureret måde at hente og ændre sitets data udefra – uden at skrabe HTML eller røre databasen direkte. Alligevel er det for mange et diffust begreb, noget „udviklerne“ taler om.

Denne guide gør det konkret: hvad API’et er, hvordan du prøver det på få minutter, og hvad det kan bruges til i en almindelig dansk webforretning.

Før du ændrer noget: Øvelserne med at læse data er ufarlige. Når du begynder at skrive data via API’et, så test på et staging-site eller med kladder, og brug en dedikeret bruger med begrænsede rettigheder – aldrig din egen administratorkonto.

1. Sådan hænger det sammen

Grundidéen er, at hver indholdstype har sin faste adresse (et endpoint), og at HTTP-metoderne svarer til handlingerne:

Metode	Handling	Eksempel
GET	Læser data	/wp-json/wp/v2/posts
POST	Opretter	Nyt indlæg eller ny kladde
PUT/PATCH	Opdaterer	Ret titel eller status på et indlæg
DELETE	Sletter	Flyt et indlæg til papirkurven

Typiske endpoints er /wp-json/wp/v2/posts for indlæg, /wp-json/wp/v2/pages for sider og /wp-json/wc/v3/products for WooCommerce-produkter. Svaret kommer som JSON: struktureret tekst, som ethvert programmeringssprog og enhver integrationsplatform kan læse.

Det er hele modellen – resten er detaljer som filtrering (?per_page=5&orderby=date), sidenummerering og felter. Når du har set mønstret én gang, genkender du det overalt: WooCommerce-noden i n8n, mobilappen, der viser dine indlæg, og samspillet med webhooks.

Sidenummerering og egne indholdstyper

API’et returnerer som standard 10 elementer pr. kald og højst 100 med per_page. Skal du hente alle produkter eller indlæg, går du gennem siderne med ?page=2, ?page=3 osv. Svarets headers fortæller, hvor mange der er i alt: X-WP-Total (antal elementer) og X-WP-TotalPages (antal sider). Integrationsplatforme håndterer det ofte automatisk, men det er værd at vide, når et flow „kun henter de første ti“.

Egne indholdstyper og felter fra plugins vises kun i API’et, hvis de er registreret til det (show_in_rest). Mangler en indholdstype i /wp-json/wp/v2/, er det ofte forklaringen. Du kan se alle tilgængelige ruter ved at åbne /wp-json/ direkte.

2. Øvelse: læs data uden nøgle

Åbn en browserfane, og skriv dit domæne efterfulgt af /wp-json/wp/v2/posts?per_page=1. Du får dit seneste indlæg tilbage som JSON med titel, indhold, dato og links. Prøv også ?search=hosting (søgning) og /wp-json/wp/v2/categories (kategorier). Samme kald fra kommandolinjen ser sådan ud:

curl "https://ditdomæne.dk/wp-json/wp/v2/posts?per_page=1&_fields=id,title,link"

To vigtige pointer. For det første viser API’et kun det, der i forvejen er offentligt – kladder og private data kræver login. Men users-endpointet viser også visningsnavne og slugs for brugere med udgivne indlæg, og derfor begrænser sikkerhedshærdning ofte netop dét endpoint.

For det andet: bloker aldrig hele API’et i panik. Blokeditoren, mange plugins og WordPress’ egne funktioner bruger det selv. Et totalt lukket API giver præcis de fejl, vi gennemgår i WordPress REST API-fejl i Site Health og ‘Not a valid JSON response’.

3. Øvelse: skriv data med applikationskodeord

Skrivning kræver identitet, og den moderne vej er indbygget i WordPress: applikationskodeord. Gå til brugerens profil i wp-admin, find sektionen Applikationsadgangskoder, giv kodeordet et navn (fx „n8n-rapporter“), og WordPress genererer et langt kodeord. Det virker kun til API-kald – ikke på login-siden – og kan tilbagekaldes enkeltvis.

Opret en dedikeret bruger til formålet med mindst nødvendige rolle. Skal integrationen kun oprette kladder, er forfatter-rollen nok. Brug kodeordet med basic auth over HTTPS – WordPress tilbyder normalt kun applikationskodeord, når sitet kører HTTPS. Et kald, der opretter en kladde, kan se sådan ud:

curl -X POST "https://ditdomæne.dk/wp-json/wp/v2/posts" \
  -u "api-bruger:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test fra API","status":"draft"}'

Til WooCommerce-data bruges i stedet WooCommerces egne API-nøgler (consumer key og consumer secret), som du opretter under WooCommerce → Indstillinger → Avanceret → REST API. Hver nøgle er knyttet til en bruger og kan have læse-, skrive- eller læse/skrive-rettighed.

Testen: opret en kladde via et POST-kald, og se den dukke op i wp-admin. Slet den bagefter, og tilbagekald testkodeordet, hvis du ikke skal bruge det igen.

4. Når kaldet fejler: de typiske svar

API’et svarer med HTTP-statuskoder og en JSON-fejl med en kode, der fortæller, hvad der gik galt:

Svar	Typisk betydning	Hvad du tjekker
401 Unauthorized	Mangler eller forkert autentificering	Brugernavn, applikationskodeord og at kaldet går over HTTPS
403 Forbidden	Brugeren må ikke udføre handlingen, eller et sikkerhedslag blokerer	Brugerens rolle, sikkerhedsplugin, firewall eller WAF
404 med rest_no_route	Endpointet findes ikke	Stavning af adressen, om pluginnet er aktivt, og om permalinks virker
400 Bad Request	Ugyldige data i kaldet	JSON-formatet og feltnavne
5xx	Fejl på serveren	PHP-fejlloggen på samme tidspunkt

Får du HTML i stedet for JSON tilbage, er det ofte en login-side, en cookiebanner-side eller en fejlside fra et sikkerhedslag, der har fanget kaldet. Se også 403 Forbidden i WordPress og permalinks og 404.

5. Hvad det bruges til i praksis

• Rapporter: mandagsrapporten henter ordredata via WooCommerces API.
• Indholdsflows: et script opretter ugens produktnyheder som kladder, og redaktøren godkender.
• Bulk-ændringer: priser eller lagertal opdateres programmatisk – se prisopdateringer i bulk.
• Sammenkobling: to sites deler indhold, eller et intranet viser seneste nyheder fra hovedsitet.
• Headless: frontends bygget i andre teknologier med WordPress som redaktionelt maskinrum.

Fællesnævneren er, at WordPress forbliver sandhedskilden, og API’et er den ordnede vej ind og ud – i modsætning til skrøbelige løsninger som direkte databaseændringer, skærmskrab eller CSV-jonglering.

6. God skik: ydelse, faldgruber og sikkerhed

Ydelse: hent i sider (per_page), spørg kun efter de felter, du bruger (_fields=id,title), og kør tunge jobs uden for spidsbelastning. API-kald belaster serveren på samme måde som dynamiske sidevisninger, og tusind kald i minuttet kan mærkes på et lille webhotel.

Faldgruber: cache-lag kan give forældede svar på GET-kald, så /wp-json/ bør normalt undtages fra sidecache. Sikkerhedsplugins og firewalls blokerer nogle gange API’et bredere end tænkt, og rate limiting kan give 429 Too Many Requests ved mange kald.

Sikkerhed: én nøgle pr. integration, mindste rettighed, rotér ved mistanke, og før log over, hvem der har hvilke nøgler. Hele disciplinen står i integrationssikkerhed: API-nøgler og tokens.

Læs også

• Hub: Automatisering og integrationer
• Webhooks forklaret
• WordPress REST API-fejl i Site Health
• WP-CLI for begyndere
• WordPress hosting hos Hostious – LiteSpeed, NVMe og staging fra WP StartUp

Ofte stillede spørgsmål om WordPress REST API

Er REST API’et en sikkerhedsrisiko?

Ikke i sig selv: uden login viser det kun offentligt indhold, og skrivning kræver autentificering. Hærd de få følsomme endpoints, fx brugerlisten, og lad resten være – et totalt lukket API giver flere fejl end sikkerhed.

Hvad er et applikationskodeord?

Et særskilt kodeord pr. integration, oprettet på brugerens profil. Det virker kun til API-kald, ikke til login, og kan tilbagekaldes enkeltvis uden at røre brugerens rigtige adgangskode.

Skal jeg kunne programmere for at bruge API’et?

Nej. Integrationsplatforme som n8n og Make pakker kaldene ind i noder, hvor du vælger handling og udfylder felter. Forståelsen af GET/POST-mønstret gør dig bare bedre til at fejlsøge dem.

Hvorfor får jeg 401 eller 403, når jeg prøver at skrive data?

401 betyder typisk, at autentificeringen mangler eller er forkert. 403 betyder, at brugeren ikke har rettighed til handlingen, eller at et sikkerhedsplugin eller en firewall blokerer kaldet.