API – hvad er et API og hvordan anvendes det?

Et API er en programmeringsgrænseflade, der lader systemer udveksle data eller udløse funktioner efter faste regler. API’er bruges blandt andet til webapps, betalingsløsninger, chatbots og AI-modeller, fordi de gør det muligt at koble software sammen uden at dele hele den bagvedliggende kode.

Hvad betyder API i praksis?

API står for application programming interface. På dansk kan det oversættes til en programmeringsgrænseflade: et aftalt kontaktpunkt, hvor et program kan bede et andet program om data, beregning eller handling. Et API er derfor ikke selve databasen, appen eller serveren. Det er den kontrollerede adgangsflade, som fortæller, hvad andre systemer må spørge om, hvordan de skal spørge, og hvad de kan forvente som svar.

Den praktiske værdi ligger i afgrænsningen. Et system kan give adgang til bestemte funktioner uden at åbne hele den interne kode. En webshop kan sende en betaling til en betalingsudbyder. En kalenderapp kan hente møder fra en anden tjeneste. En AI-løsning kan sende tekst, lyd eller data til en model og modtage et struktureret svar. I alle tilfælde fungerer API’et som en kontrakt mellem systemerne.

Et API kan være offentligt, privat eller partnerbaseret. Et offentligt API kan bruges af eksterne udviklere efter dokumenterede regler. Et privat API bruges kun internt i en organisation. Et partner-API ligger midt imellem og gives til udvalgte leverandører, kunder eller samarbejdspartnere.

Hvordan fungerer et API mellem to systemer?

Et API fungerer normalt som en udveksling mellem en klient og en server. Klienten sender en forespørgsel med en bestemt adresse, metode, data og eventuelt adgangstoken. Serveren behandler forespørgslen og returnerer et svar, typisk med data, statuskode og metadata. Det er samme grundmønster, uanset om klienten er en mobilapp, et dashboard, en integration, et script eller en AI-agent.

En typisk forespørgsel kan betyde: hent kundens seneste ordrer, opret en ny supportbillet, send en besked, start en beregning eller returner en liste med tilgængelige dokumenter. API’et bestemmer både, hvilke handlinger der findes, og hvilke oplysninger der skal sendes med for at handlingen kan udføres.

API’et skjuler også kompleksitet. Klienten behøver ikke kende databasestruktur, interne beregninger, serveropsætning eller forretningslogik. Den skal kun følge grænsefladens regler. Den afgrænsning gør API’er nyttige i moderne software, hvor mange systemer skal arbejde sammen uden at være bygget som ét stort program.

Hvilke dele består et web-API af?

Et web-API består af flere faste elementer. De vigtigste er endpointet, metoden, de data der sendes ind, de data der returneres, og reglerne for adgang. Endpointet er adressen på den ressource eller handling, klienten vil bruge. Metoden fortæller, om klienten vil hente, oprette, ændre eller slette noget. Svaret fortæller, om handlingen lykkedes, og hvad serveren returnerede.

For læseren uden kodebaggrund er endpointet ofte den mest konkrete del. Hvis et system for eksempel har et endpoint til kundeoplysninger og et andet til fakturaer, kan adgang, logning og fejlhåndtering styres forskelligt for de to områder.

Hvordan adskiller REST, HTTP og OpenAPI sig?

HTTP, REST og OpenAPI blandes ofte sammen, men de beskriver forskellige lag. HTTP er protokollen, som blandt andet definerer metoder, headers, statuskoder, indhold og URI’er. Mange web-API’er bruger HTTP, fordi protokollen allerede er udbredt på nettet og understøttes af browsere, servere, sikkerhedsværktøjer og udviklingsmiljøer.

REST er en arkitekturstil for netværksbaseret software. I praksis bruges ordet ofte om API’er, hvor ressourcer adresseres via URL’er, og hvor HTTP-metoder bruges med tydelige betydninger. Ikke alle API’er, der kaldes REST, følger alle REST-principper stramt. Derfor er det mere præcist at se REST som et designideal end som et filformat.

OpenAPI er noget tredje: en standardiseret beskrivelse af et HTTP-API. En OpenAPI-beskrivelse kan dokumentere paths, operationer, request bodies, responses, schemas og sikkerhedsordninger. Den kan læses af mennesker, men også bruges af værktøjer til dokumentation, test og generering af klientkode.

Hvilke typer API’er møder du ofte?

API’er findes på flere niveauer. Browser-API’er giver webapps adgang til funktioner i browseren, for eksempel geolocation, lyd, video, dokumentstruktur eller lokal lagring. Tredjeparts-API’er giver adgang til en ekstern tjeneste, for eksempel kort, betaling, mail, regnskab, beskeder eller AI-modeller. Interne API’er binder en organisations egne systemer sammen.

• Web-API’er bruges over netværk og er ofte baseret på HTTP.
• Biblioteks-API’er bruges i kodepakker, hvor et program kalder funktioner lokalt.
• Operativsystem-API’er giver programmer adgang til filer, netværk, enheder og systemfunktioner.
• Webhook-API’er sender beskeder fra ét system til et andet, når en begivenhed sker.
• Model-API’er giver adgang til AI-modeller, embeddings, talegenkendelse, billedanalyse eller tekstgenerering.

Forskellen betyder noget for ansvar. Et browser-API afhænger af brugerens browser og tilladelser. Et betalings-API afhænger af leverandørens regler og sikkerhed. Et internt API afhænger af organisationens egen drift, versionering og adgangsstyring.

Hvordan bruges API’er i AI og automatisering?

API’er er en vigtig del af moderne kunstig intelligens, fordi AI-systemer sjældent står alene. En chatbot skal måske hente kundedata, slå en ordre op, sende en besked eller gemme en sag. En analysemodel skal måske modtage data fra et lager, returnere en klassifikation og sende resultatet videre til et dashboard.

I en chatbot er API’et ofte forbindelsen mellem dialogen og de systemer, der faktisk kan udføre noget. Botten kan svare på almindelige spørgsmål ud fra statisk viden, men en aktuel ordrestatus kræver adgang til et ordresystem. Her skal API’et kontrollere identitet, rettigheder, datagrundlag og fejltilfælde.

API’er gør også automatisering mere kontrollerbar end manuel kopiering mellem systemer. Når et API er stabilt dokumenteret, kan en arbejdsgang gentages, logges og testes. Det er især relevant i processer med mange ensartede trin, for eksempel sagsoprettelse, dataopslag, rapportering, berigelse af kundedata eller synkronisering mellem fagsystemer.

Hvad skal du kontrollere i API-dokumentation?

API-dokumentation er ikke kun en vejledning til udviklere. Den er også et kontrolgrundlag for drift, sikkerhed og indkøb. Før en integration bygges, bør dokumentationen gøre det tydeligt, hvilke endpoints der findes, hvilke felter der er påkrævede, hvilke fejl der kan opstå, og hvilke begrænsninger der gælder.

• Hvilke endpoints findes, og hvilke handlinger understøtter de?
• Hvilke datatyper, felter og svarformater skal bruges?
• Hvordan håndteres autentifikation, adgangsroller og token-udløb?
• Findes der rate limits, kvoter eller begrænsninger på store forespørgsler?
• Hvordan varsles ændringer, versioner og udfasning af gamle felter?
• Er fejlbeskeder præcise nok til, at en integration kan rette eller gentage en forespørgsel sikkert?

Hvis dokumentationen er uklar, flytter risikoen sig til integrationen. Udviklere kan begynde at gætte på formater, bruge felter forkert eller mangle håndtering af fejl. OpenAPI-beskrivelser kan reducere den risiko, fordi de gør dele af API-kontrakten maskinlæsbar.

Hvordan bygges en simpel API-integration trin for trin?

En API-integration bør begynde med forretningsformålet, ikke med teknikken. Først afklares, hvilken handling integrationen skal understøtte: hente data, opdatere en sag, oprette en bruger, berige en rapport eller sende et svar til et andet system. Derefter kortlægges de data, der er nødvendige for at gøre handlingen sikkert og korrekt.

1. Definer den konkrete handling og de data, der må udveksles.
2. Find relevante endpoints, metoder og adgangskrav i dokumentationen.
3. Test forespørgsler i et testmiljø med ufarlige data.
4. Byg fejlhåndtering for afviste forespørgsler, udløbne tokens og midlertidige driftsfejl.
5. Log tekniske hændelser uden at gemme flere personoplysninger end nødvendigt.
6. Overvåg drift, svarhastighed, kvoter og ændringer i API-versioner.

Den rækkefølge passer også til integrering af AI i eksisterende kundeservicesystemer. Før AI kobles på en arbejdsgang, skal det være klart, hvilke systemer modellen må bruge, hvilke data den må modtage, og hvilke handlinger der kræver menneskelig godkendelse.

Hvilke data- og sikkerhedsrisici følger med API’er?

API’er skaber værdi, fordi de åbner adgang til funktioner og data. Den samme adgang kan skabe risiko, hvis grænserne er for brede, adgangskontrollen er svag, eller dokumentationen ikke afspejler den faktiske implementering. Sikkerhed handler derfor både om teknik, dataminimering og løbende styring.

API-nøgler, tokens og klienthemmeligheder skal behandles som adgangsmidler. De bør ikke placeres i offentlig kode, sendes i URL’er eller deles i uautoriserede værktøjer. Følsomme oplysninger i URL’er kan ende i logs, browserhistorik, fejlrapporter og mellemled. Brug af headers, korte token-levetider, rettighedsafgrænsning og sikre hemmelighedslagre reducerer risikoen.

OWASP fremhæver blandt andet brud på objektniveau-adgang, fejl i autentifikation, ukontrolleret ressourceforbrug, sikkerhedsfejl i konfiguration, manglende API-fortegnelse og usikker brug af andre API’er. Derfor bør API-sikkerhed ses som en del af den samlede AI-sikkerhed og tekniske standarder, især når API’et bruges til automatiserede beslutninger eller AI-understøttede arbejdsgange.

Hvordan vurderer du kvaliteten af et API?

Et godt API er ikke kun et API, der virker i en enkelt test. Det er et API, der er forståeligt, stabilt, sikkert og forudsigeligt over tid. Kvaliteten viser sig ofte først, når integrationen skal håndtere fejl, høj belastning, ændrede datafelter eller flere brugertyper med forskellige rettigheder.

Kvalitet hænger også sammen med databehandling. Hvis API’et leverer ufuldstændige, forsinkede eller uklart definerede data, kan downstream-systemer træffe forkerte valg. Det gælder især i data-processering, hvor hvert trin afhænger af, at input er forstået korrekt.

Hvornår bør en organisation bruge et API i stedet for manuel eksport?

Et API giver mest mening, når data skal udveksles ofte, sikkert og med lav fejlmargin. Manuel eksport kan være nok til en enkeltstående rapport eller en sjælden overførsel. Når opgaven gentages dagligt, kræver sporbarhed eller indgår i en kunde- eller produktionsproces, bliver et API typisk mere robust.

En organisation bør især vælge API-adgang, når flere systemer skal dele aktuelle data, når ændringer skal ske tæt på realtid, eller når fejl i kopiering kan få praktiske konsekvenser. API’et kan gøre processen mere ensartet, men det fjerner ikke behovet for datakvalitet, rettighedsstyring og ansvar for fejl.

API’er er også relevante ved integrationer mellem egne systemer og leverandørers platforme. Her bør kontrakten afklare oppetid, support, versionsændringer, datalagring, adgangslogning og exit-muligheder. Uden de afklaringer kan en teknisk integration blive svær at vedligeholde, selv om den første prototype virker.

Hvilke begrænsninger har API’er?

Et API kan kun give adgang til de funktioner, der er udstillet. Hvis et endpoint ikke findes, kan integrationen ikke bruge funktionen direkte. Hvis API’et kun returnerer bestemte felter, kan klienten ikke antage, at resten af systemets data er tilgængelige. Et API er derfor en afgrænset aftale, ikke en fuld kopi af et system.

API’er kan også være begrænset af kvoter, svartider, prisstruktur, driftsvinduer, datakvalitet, adgangsroller og versioner. En integration, der virker i en lille test, kan opføre sig anderledes, når den skal håndtere mange samtidige brugere eller store datamængder. Derfor bør belastning, fejltilfælde og ændringer testes tidligt.

Ved AI-brug kommer der et ekstra lag. API’et kan levere data til en model eller modtage et modelresultat, men API’et gør ikke automatisk resultatet korrekt, fair eller egnet til beslutninger. Modelvalg, datagrundlag, evaluering, menneskelig kontrol og organisatorisk ansvar ligger uden for selve API-kontrakten.

Hvordan ser et godt API-setup ud i praksis?

Et godt API-setup kombinerer teknisk klarhed med organisatorisk styring. Det har dokumenterede endpoints, testmiljø, versionering, logning, overvågning og en plan for ændringer. Det har også klare roller: hvem må oprette adgang, hvem ejer data, hvem reagerer på fejl, og hvem godkender nye integrationer.

For udviklere er den tekniske oplevelse vigtig: ensartede navne, klare fejlbeskeder, realistiske eksempler og mulighed for test uden produktionsdata. For ledelse og drift er styring vigtigere: adgangsfortegnelse, auditspor, risikovurdering, leverandørstyring og mulighed for at lukke en integration uden at lamme resten af forretningen.

Den bedste indikator er ofte, om API’et kan forklares enkelt. Hvis teamet kan beskrive, hvilke data der må flyde, hvorfor de flyder, hvem der har adgang, og hvordan fejl håndteres, er grænsefladen mere end en teknisk forbindelse. Den er en kontrolleret del af systemlandskabet.

Hvilke kilder ligger til grund?

Definitionen af API’er og forskellen mellem browser-API’er og tredjeparts-API’er bygger blandt andet på MDN Web Docs’ introduktion til web-API’er. Forklaringen af HTTP-metoder, semantik og risikoen ved følsomme oplysninger i URL’er bygger på IETF RFC 9110 om HTTP Semantics.

Beskrivelsen af API-dokumentation og maskinlæsbare kontrakter bygger på OpenAPI Specification v3.2.0. Sikkerhedsafsnittet er desuden kontrolleret mod OWASP API Security Top 10 fra 2023.