Hvad er et API, og hvorfor har dit system brug for et?

Et API er en aftalt indgang til et system som andre programmer kan bruge til at hente og sende data automatisk uden at et menneske sidder imellem og taster. Spørger du hvad et API er i praksis, så er det grunden til at en ordre i din webshop kan blive til en faktura i regnskabsprogrammet og en kontakt i dit CRM uden at nogen kopierer noget fra én skærm til en anden.

Har dit system et API, kan det kobles sammen med resten af forretningen. Har det ikke, bliver det en ø hvor data skal flyttes i hånden. Nedenfor forklarer jeg det hele uden en eneste linje kode, med eksempler fra de systemer de fleste virksomheder allerede bruger.

Den korte version: hvad et API gør for din forretning

Den nemmeste måde at forstå et API på er at se forskellen i hverdagen, her i en virksomhed der sælger via en webshop.

Min tommelfingerregel: tastes den samme oplysning ind i to systemer flere gange om ugen, bør du undersøge om et API kan overtage jobbet. Hvor integrationer hører hjemme i et større forløb, kan du se i min guide til hvordan et softwareprojekt foregår fra idé til drift.

Hvad er et API? Forklaret uden kode

API står for Application Programming Interface, på dansk en programmeringsgrænseflade. Princippet kender du fra en grossist med en bestillingsblanket. Du går ikke selv ind på lageret og tager varerne. Du afleverer en blanket i et fast format ved skranken og får en kvittering tilbage i et fast format. Er blanketten udfyldt forkert, får du den retur med en begrundelse.

Et API fungerer på samme måde, bare mellem to programmer. Der indgår fem ting:

• Forespørgslen: det ene system beder om noget, fx "giv mig alle ubetalte fakturaer" eller "opret denne kunde".
• Svaret: det andet system svarer i et fast format, typisk JSON (struktureret tekst som maskiner let kan læse), med en kode der fortæller om det lykkedes.
• Adressen: hver slags data har sin egen adresse, et såkaldt endpoint. Én til kunder, én til fakturaer og så videre.
• Nøglen: adgang kræver en nøgle eller et login så systemet ved hvem der spørger, og hvad de har lov til.
• Dokumentationen: beskrivelsen af hvad man kan bede om, og i hvilket format. Et API uden god dokumentation er som en blanket uden vejledning.

Det vigtigste for dig er at et API er en kontrakt. Systemet lover at svare på en bestemt måde så længe man spørger på en bestemt måde. Derfor kan to systemer fra hver sin leverandør arbejde sammen uden at kende hinandens indre. API'et er en del af systemets backend, og hvordan backend hænger sammen med resten, har jeg forklaret i hvad en tech stack er.

To begreber bliver ofte blandet sammen: API'et er stikkontakten, og integrationen er ledningen og apparatet. API'et stiller systemet selv til rådighed, og integrationen er den kode nogen skriver for at bruge det. Hvordan sådan en integration bygges i praksis, gennemgår jeg i guiden til at koble dit system sammen med e-conomic, Dinero og andre.

Et eksempel: én ordre gennem seks systemer

Forestil dig en virksomhed der sælger kaffe og kaffemaskiner til kontorer via en webshop. En kunde bestiller en kasse kaffebønner og et sæt kopper. Sådan bevæger ordren sig når systemerne er koblet sammen via API'er:

1. Kunden trykker "Betal". Webshoppen beder betalingsudbyderen om at trække beløbet via betalingsudbyderens API.
2. Betalingsudbyderen giver besked tilbage når betalingen er gennemført. Det kaldes en webhook: i stedet for at webshoppen spørger hvert minut, sender betalingsudbyderen selv beskeden.
3. Webshoppen opretter en faktura i regnskabsprogrammet med kunde, varelinjer og moms. For at det kan lade sig gøre, har virksomheden på forhånd godkendt adgangen. I e-conomic sker det ved at virksomheden godkender appen, som derefter får en nøgle til netop det regnskab.
4. Lagersystemet får besked om at reservere varerne, og webshoppen henter den nye lagerstatus så den næste kunde ikke køber noget der er udsolgt.
5. Fragtfirmaets API laver en fragtlabel og et trackingnummer, som automatisk sendes til kunden på mail.
6. CRM-systemet får kunden og ordren så sælgeren kan se historikken før næste opkald.

Seks systemer og ingen indtastninger. Uden API'er ville hvert trin være en person der kopierer oplysninger mellem skærme. Med få ordrer om dagen kan det sagtens klares i hånden. Med mange bliver det en tidsrøver og en fast kilde til fejl.

Læg mærke til at systemerne ikke alle taler direkte med hinanden. Webshoppen styrer forløbet og kalder de andre, og hvilket system der får den rolle, er en af de første beslutninger i et integrationsprojekt.

Hvorfor har dit system brug for et API?

Når folk spørger om deres system har brug for et API, mener de ofte to forskellige ting, og de har hver sit svar.

Dit system skal kunne bruge andre systemers API'er

Det er det mest almindelige behov. Næsten alle forretningssystemer skal tale med regnskab, betaling, mail og ofte et CRM. Bygger du en webapp eller en kundeportal, bør den fra start være lavet så den kan sende og hente data fra de systemer du allerede har. Ellers ender medarbejderne med at flytte data i hånden, og så mister systemet en stor del af sin værdi.

Dit system kan få sit eget API

Det næste skridt er at dit eget system stiller et API til rådighed for andre. Det er relevant når:

• Du vil have en mobilapp senere. En app taler med det samme system som webudgaven, og det sker via et API.
• Kunder eller partnere vil koble sig på. En B2B-kunde vil måske sende ordrer direkte fra sit eget indkøbssystem i stedet for at bruge din webshop.
• Du vil kunne skifte værktøjer uden at starte forfra. Kan dine data hentes ud via et API, står du stærkere, og det er en af de bedste måder at undgå at blive låst fast hos én leverandør.
• Du vil automatisere med værktøjer som Zapier, Make eller AI-assistenter. De har alle brug for en indgang til dine data.

Men byg det først når der er en konkret bruger af det. Et API som ingen bruger, er bare mere kode at vedligeholde og beskytte. Min anbefaling er at bygge systemet så et API er let at tilføje, og så vente med selve API'et til nogen står og mangler det.

Det skal du afklare før dit system kobles sammen

Selve kaldet til et API er sjældent det svære. Timerne og risikoen ligger i alt det omkring det. Det er de her fem ting jeg altid afklarer før jeg giver en pris.

Adgang og nøgler

En API-nøgle er et kodeord for et program. Den hører hjemme på serveren og ikke i en mail eller et regneark. Mange udbydere har desuden adskilte nøgler til test og drift. Stripe har fx separate nøgler til testmiljø og rigtige betalinger og anbefaler nøgler der kun har de rettigheder integrationen faktisk bruger. Sørg også for at kontoen og nøglerne står i virksomhedens navn og ikke i en tidligere medarbejders eller udviklers navn.

Begrænsninger på antal kald

De fleste API'er har en grænse for hvor mange forespørgsler man må sende. Hos HubSpot er grænsen for private apps på gratis- og Starter-planerne 100 kald pr. 10 sekunder og 250.000 kald i døgnet. Det er rigeligt til daglig drift, men en første import af mange tusinde kontakter skal planlægges så den ikke bliver afvist halvvejs.

Ændringer og versioner

API'er ændrer sig. Udbydere udfaser gamle versioner, og så skal integrationen tilpasses. Budgettér med løbende vedligehold, og aftal hvem der holder øje med udbydernes meddelelser.

Fejl og overvågning

Hvad sker der når det andet system er nede i en time? En god integration prøver igen, logger fejlen og giver besked til en person. Den dyreste fejl er den der sker i stilhed i tre uger indtil nogen opdager at fakturaerne aldrig nåede regnskabet.

Persondata og sikkerhed

Flytter integrationen oplysninger om personer til en leverandør der behandler dem på dine vegne, er leverandøren typisk databehandler, og så skal der være en databehandleraftale. Datatilsynet forklarer rollefordelingen mellem dataansvarlig og databehandler. Spørg en rådgiver hvis du er i tvivl om din situation. Får dit system sit eget API, skal det desuden beskyttes lige så grundigt som resten af systemet. De klassiske huller er gennemgået i tjeklisten over sårbarheder alle webapps skal beskyttes mod.

Sådan tjekker du om et system har et brugbart API

Du behøver ikke være udvikler for at lave den første vurdering. Overvejer du et nyt system, eller vil du koble to eksisterende sammen, så gå de her trin igennem:

1. Find dokumentationen. Søg på systemets navn og "API" eller "developer". Offentlig og opdateret dokumentation er et godt tegn. Skal du igennem en sælger for at se den, er det et dårligt tegn.
2. Tjek hvilke data du kan læse og skrive. Mange API'er kan læse fakturaer, men ikke oprette dem, eller håndterer kunder, men ikke de ekstra felter I har tilføjet.
3. Tjek om API-adgang følger med jeres abonnement. Hos nogle udbydere kræver det en bestemt pakke eller koster ekstra.
4. Tjek om systemet selv kan give besked via webhooks. Ellers skal integrationen spørge med faste mellemrum, hvilket giver forsinkelse og flere kald.
5. Tjek om der er et testmiljø. e-conomic tilbyder fx en gratis prøveadgang med demodata, og Stripe har et separat testmiljø så integrationen kan afprøves uden at røre rigtige data.
6. Tjek begrænsningerne. Hvor mange kald må man lave, og hvor store mængder data kan hentes ad gangen?
7. Skriv ned hvilke data der skal flyttes, hvornår, og hvilket system der har ret hvis to systemer er uenige. Det hører hjemme i kravspecifikationen til projektet.

Kan du svare ja til de første fem punkter, er der et godt fundament at bygge på. Er svaret nej til flere af dem, så tal med en udvikler før du binder dig til systemet.

Hvornår du ikke har brug for et API

Jeg bygger selv integrationer, så tag dette afsnit med det forbehold. Men der er mange situationer hvor det ikke kan betale sig at få bygget noget:

• Du har få transaktioner. Sender du ti fakturaer om måneden, tager det kortere tid at taste dem end at bygge, teste og vedligeholde en integration.
• Der findes en færdig kobling. De fleste store systemer har en app-butik eller en liste over færdige integrationer. Et abonnement er næsten altid billigere end udvikling og vedligehold.
• Et automatiseringsværktøj kan klare det. Zapier og Make bruger systemernes API'er for dig og passer fint til enkle arbejdsgange som "ny formular, ny kontakt". Når logikken bliver kompliceret eller fejl skal håndteres ordentligt, når de til gengæld hurtigt deres grænse.
• En fil er nok. Skal din revisor bruge en månedlig oversigt, er en eksport til et regneark ofte helt fint.
• Systemet har slet ikke et API. Så er det rigtige spørgsmål som regel om I skal skifte system, ikke om nogen skal bygge en skrøbelig omvej.

Næste skridt

Skal du have bygget en integration, så gør det her klar før den første samtale med en udvikler. Det sparer dig for møder, og du får et mere præcist estimat.

Jeg bygger webapps, kundeportaler og interne systemer der taler med jeres regnskab, CRM og betaling. Se hvordan jeg griber det an på siden om udvikling af webapps og platforme.

Ofte stillede spørgsmål

Hvad er et REST API?+

Et REST API er den mest udbredte måde at bygge API'er på over nettet. Hver slags data har sin egen adresse, og man bruger nettets standardkommandoer til at hente, oprette, rette og slette. Svaret kommer typisk som JSON. Du kan også møde GraphQL og ældre SOAP-API'er, især i ERP-systemer. Som køber er typen mindre vigtig end om API'et er veldokumenteret og stabilt.

Koster det penge at bruge et API?+

Ofte ikke direkte, men der er næsten altid en pris et sted. Nogle udbydere kræver en bestemt abonnementspakke for at åbne for API'et, og andre tager betaling pr. kald eller pr. transaktion, fx for SMS, betalinger eller AI-tjenester. Dertil kommer udvikling og vedligehold af selve integrationen. Spørg derfor både udbyderen og udvikleren om de løbende udgifter.

Kan man lave en integration uden et API?+

Ja, men det er skrøbeligt. Alternativerne er at udveksle filer, fx en CSV-eksport der hentes hver nat, eller at lade et program klikke sig igennem skærmbillederne som en person. Den sidste løsning går i stykker, hver gang leverandøren ændrer sit design. Brug det kun som en midlertidig løsning, og overvej om et system med et ordentligt API er det bedre valg på sigt.

Er det en sikkerhedsrisiko at åbne et API?+

Et API er en dør ind til dit system, så det er kun sikkert hvis døren er låst ordentligt. Det kræver login eller nøgler, rettigheder der styrer hvem der må se hvad, krypteret forbindelse, grænser for antal kald og logning. De mest almindelige fejl er et API der sender flere data med end nødvendigt, eller som ikke tjekker om brugeren må se netop den post.