Kort svar: WordPress’ REST API gør alt indhold tilgængeligt som data på faste URL’er under
/wp-json/: indlæg, sider, brugere, medier – og med WooCommerce også produkter og ordrer. LÆSNING af offentligt indhold kræver ingen nøgle (prøv selv/wp-json/wp/v2/postsi browseren); SKRIVNING kræver autentificering – nemmest med et applikationskodeord på en dedikeret bruger med mindste 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 pludselig, hvordan hele automatiseringsverdenen taler med dit site.
REST API’et er WordPress’ officielle bagdør for venner: en struktureret, sikker måde at hente og ændre sitets data udefra – uden at skrabe HTML eller røre databasen. 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 om tre minutter, og hvad det kan bruges til i en almindelig dansk web-forretning.
Grundidéen: hver indholdstype har sin faste adresse – /wp-json/wp/v2/posts for indlæg, /wp-json/wp/v2/pages for sider, /wp-json/wc/v3/products for WooCommerce-produkter – og de fire HTTP-metoder svarer til de fire handlinger: GET læser, POST opretter, PUT/PATCH opdaterer, DELETE sletter. Svaret kommer som JSON: struktureret tekst, 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 webhooks’ makkerskab med API’et – alle taler de samme fire verber mod de samme faste adresser.
Å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. Det føles underligt første gang: alt offentligt indhold ER offentligt som data. Prøv også ?search=hosting (søgning) og /wp-json/wp/v2/categories (kategorier). To vigtige pointer: API’et eksponerer kun det, der i forvejen er offentligt – kladder og private data kræver login – men det eksponerer OGSÅ brugernes visningsnavne via users-endpointet, hvilket er grunden til, at sikkerhedshærdning ofte begrænser netop dét. Og blokerér aldrig hele API’et i panik: WordPress-editoren, mange plugins og hele blok-redigeringen BRUGER det selv – et totalt lukket API giver præcis de mærkelige fejl, vi fejlsøger i REST API-fejlguiden.
Skrivning kræver identitet, og den moderne vej er indbygget: applikationskodeord. Gå til brugerens profil i wp-admin, find sektionen Applikationsadgangskoder, giv den et navn („n8n-rapporter“) – og WordPress genererer et langt kodeord, der KUN virker til API-kald (aldrig til login-siden) og kan tilbagekaldes enkeltvist. Opret en DEDIKERET bruger til formålet med mindste nødvendige rolle – skal integrationen kun oprette kladder, er forfatter-rollen nok – og brug så kodeordet i dine kalds autentificering (basic auth over HTTPS). Til WooCommerce-data bruges i stedet Woo’s egne API-nøgler (consumer key/secret under WooCommerce → Avanceret → REST API) med læse- eller skriveret pr. nøgle. Testen: opret en kladde via et POST-kald, og se den dukke op i wp-admin – det øjeblik plejer at tænde automatiserings-gnisten for alvor.
Fem hverdagseksempler fra denne hubs verden: rapporter – mandagsmailen henter ordredata via Woo-API’et; indholdsflows – et skript opretter ugens produktnyheder som kladder, redaktøren godkender; bulk-ændringer – priser eller lagertal opdateres programmatisk (detaljerne i bulk-prisguiden); sammenkobling – to sites deler indhold, eller et intranet viser seneste nyheder fra hovedsitet; headless – hele frontends bygget i andre teknologier med WordPress som redaktionelt maskinrum. Fællesnævneren: WordPress forbliver sandhedskilden, og API’et er den ordnede vej ind og ud – i skarp kontrast til de skrøbelige løsninger, folk griber til uden det (databasehack, skærmskrab, CSV-jonglering).
Tre ting adskiller pæn API-brug fra problemskabende. Ydelse: hent i sider (per_page), spørg kun efter de felter, du bruger (_fields=id,title), og kør tunge jobs i lavtrafik-timer – API-kald er almindelige sideindlæsninger for serveren, og tusind kald i minuttet mærkes på små webhoteller (på ordentlig WordPress-hosting er der til gengæld længere til grænsen). Fælder: cache-lag kan give forældede svar på GET-kald (undtag /wp-json/ fra sidecache), og sikkerhedsplugins blokerer nogle gange API’et bredere end tænkt. Sikkerhed: én nøgle pr. integration, mindste rettighed, rotér ved mistanke, og log hvem der har hvilke – hele disciplinen står i integrationssikkerheds-guiden. Med de tre på plads er API’et præcis, hvad det er tænkt som: den stabile bro mellem dit site og alt det, der gør det klogere.
Ikke i sig selv: det viser kun offentligt indhold uden login, og skrivning kræver autentificering. Hærd de få følsomme endpoints (brugerlisten), og lad resten være – totalt lukket API giver flere fejl end sikkerhed.
Et særskilt kodeord pr. integration, oprettet på brugerens profil: virker kun til API-kald, aldrig til login – og kan tilbagekaldes enkeltvist uden at røre brugerens rigtige kodeord.
Nej – integrationsplatforme som n8n og Make pakker kaldene ind i noder, hvor du bare vælger handling og udfylder felter. Forståelsen af GET/POST-mønstret gør dig bare langt bedre til at fejlsøge dem.
