API-integration forklaret: Sådan får virksomheder systemer til at arbejde sammen.

Hvad er en API?

Et API - Application Programming Interface - er en teknisk grænseflade, som gør det muligt for software at kommunikere med anden software efter definerede regler.

Et CRM kan eksempelvis have API-endpoints til at:

• hente en kunde
• oprette en kunde
• opdatere en kontaktperson
• hente ordrer
• ændre en status

Et endpoint er blot en bestemt adresse eller funktion i API'et. Ét endpoint kan eksempelvis bruges til kunder, et andet til ordrer.

API'et beskriver dermed, hvad et system tillader andre systemer at læse eller gøre. Det beskriver ikke nødvendigvis hele den forretningsproces, virksomheden vil automatisere.

Hvad er en API-integration?

API'et er grænsefladen. Integrationen er den konkrete løsning, der bruger grænsefladen.

Forestil jer:

CRM -> integration -> økonomisystem

Integrationen skal blandt andet beslutte:

• hvilke kunder der skal sendes
• hvilke felter der skal mappes
• hvilket system der ejer hvert felt
• hvornår data skal flyttes
• hvordan data valideres
• hvad der sker ved fejl
• hvordan dubletter undgås
• hvordan driften overvåges

Det er derfor ofte logikken mellem systemerne, der er den svære del. Et API-kald kan være enkelt, mens den korrekte forretningsregel kræver langt mere afklaring.

Et konkret eksempel på en API-integration

Forestil jer en webshop, hvor en godkendt ordre skal oprettes i økonomisystemet.

Et simpelt flow kan se sådan ud:

1. Webshoppen registrerer, at ordren er godkendt.
2. Integrationen henter de relevante ordre- og kundedata.
3. Data valideres.
4. Kunden matches mod en eksisterende kunde eller oprettes.
5. Ordren mappes til økonomisystemets felter.
6. Integrationen sender ordren.
7. Det eksterne ID gemmes tilbage.
8. Resultatet logges.
9. Midlertidige fejl kan forsøges igen.
10. Permanente fejl kan sendes til manuel gennemgang.

Det afgørende er ikke kun, om begge systemer "har et API". Integrationen skal vide, hvad der tæller som samme kunde, hvilke felter der er obligatoriske, og hvad der skal ske, hvis destinationen afviser data.

Hvornår giver en API-integration mening?

1. De samme data indtastes flere gange

Hvis kundeoplysninger først oprettes i CRM og derefter tastes manuelt i økonomisystem og internt værktøj, er der både tidsforbrug og risiko for forskellige versioner af samme data.

En integration kan flytte de relevante felter automatisk efter en fast regel.

2. Information skal være opdateret flere steder

Ordrestatus, betalingsstatus eller lagerdata kan være eksempler, hvor flere systemer har brug for den samme aktuelle information.

Her er spørgsmålet ikke kun, om data skal synkroniseres, men også hvor hurtigt.

3. Et website eller en webapp skal bruge data fra et andet system

En B2B-kundeportal kan eksempelvis vise dokumenter, ordrestatus eller økonomidata, som allerede findes i andre systemer.

Portalen behøver ikke selv at eje alle data. Den kan bruge integrationer til at hente eller sende de oplysninger, kunden har brug for.

4. Eksport og import gentager sig

En CSV-import én gang om måneden kan være helt fornuftig. Hvis medarbejdere derimod eksporterer og importerer data mange gange i løbet af en arbejdsdag, er processen værd at undersøge.

5. En hændelse skal starte næste trin automatisk

Eksempel:

betaling modtaget -> projekt aktiveres -> ansvarlig medarbejder varsles

Her er API'et en del af en større automatisering.

6. Data skal samles til rapportering

Hvis et dashboard skal erstatte manuelle spreadsheets, kan integrationer hente data fra de systemer, hvor de allerede opstår.

Hvornår bør man ikke bygge en API-integration?

Systemerne har allerede en god native integration

Hvis platformens egen connector dækker workflowet stabilt, er det ofte bedre at bruge den end at bygge custom.

Data flyttes sjældent

En manuel CSV-import kan være billigere og mere robust ved lav frekvens.

Kildedata er dårlige

Hvis kundenavne, IDs eller statusværdier allerede er inkonsistente, automatiserer en integration blot problemet hurtigere. Datakvaliteten bør måske løses først.

Processen er uklar

Et API kan ikke beslutte, hvem der bør eje en status, eller hvad der skal ske ved en konflikt. Den forretningsregel skal være afklaret før kode.

API'et understøtter ikke workflowet

Et system kan have et API uden at give adgang til de nødvendige endpoints, felter eller handlinger. Dokumentation og adgang bør derfor kontrolleres tidligt.

Værdien er for lav

Teknisk mulighed er ikke det samme som forretningsmæssig værdi. Hvis processen sker få gange om året, kan integrationens drift og vedligehold være dyrere end den manuelle opgave.

Start med processen - ikke endpointet

Før nogen skriver kode, bør virksomheden kunne beskrive:

• Hvilken proces skal forbedres?
• Hvor opstår data?
• Hvor skal de hen?
• Hvem bruger dem?
• Hvor hurtigt skal de være fremme?
• Hvad sker der, hvis de mangler?
• Hvad sker der, hvis destinationen er nede?
• Hvem ejer processen?

Eksempel: "Når en kunde markeres som vundet i CRM, skal kunden oprettes i økonomisystemet inden næste arbejdsdag."

Det er et bedre integrationsscope end: "Vi skal bruge customer-endpointet."

Det første beskriver trigger, forretningsværdi og timing. Det andet beskriver kun en teknisk mulighed.

Hvilket system ejer data?

En af de vigtigste beslutninger er source of truth eller system of record: Hvilket system er den autoritative kilde til et bestemt felt?

Eksempel:

CRM ejer:

• kundenavn
• sælger
• segment

Økonomisystem ejer:

• fakturaer
• betalingsstatus
• saldo

Webshop ejer:

• ordrelinjer
• produktvalg

Hvis alle systemer må ændre alle felter, bliver konflikter svære at løse. En integration bør derfor have eksplicitte regler for dataejerskab.

Envejssynkronisering eller tovejssynkronisering?

Envejssync er typisk:

A -> B

Det er ofte enklere, fordi ét system tydeligt er kilde.

Tovejssync er:

A <-> B

Det kan være nødvendigt, men øger kompleksiteten. Man skal blandt andet definere:

• hvad der sker ved samtidige ændringer
• hvilket timestamp der stoler på
• hvilket system der har prioritet
• hvordan sync-loops undgås
• hvad der sker ved delvise fejl

Tovejssynkronisering bør derfor ikke vælges, bare fordi den er teknisk mulig. Brug den, når begge systemer reelt skal kunne eje ændringer.

Data mapping: systemer kalder ikke tingene det samme

Et CRM kan kalde et felt:

customer_id

mens økonomisystemet kalder samme forretningsobjekt:

debtor_number

Integrationen skal vide, at de to hænger sammen.

Data mapping omfatter ofte:

• feltnavne
• datatyper
• obligatoriske felter
• valuta
• datoformater
• statusværdier
• lande- og sprogkoder
• interne og eksterne IDs

Det er ofte mere arbejde at få betydningen af data korrekt end at sende selve HTTP-requestet.

Validering før data sendes videre

En integration bør ikke ukritisk kopiere alt.

Eksempler på data, der bør håndteres bevidst:

• manglende e-mail
• ugyldig dato
• ukendt status
• negativ mængde
• manglende kunde-ID
• tomt obligatorisk felt

Afhængigt af processen kan integrationen:

• afvise posten
• logge fejlen
• placere posten i en kø
• bruge en defineret fallback
• sende posten til manuel gennemgang

Det vigtige er, at ugyldige data ikke forsvinder lydløst eller skaber uforudsigelige resultater.

REST API, webhook, polling eller batch?

REST API

Et REST API bruges ofte som request/response: integrationen spørger eller sender noget og får et svar.

Webhook

En webhook vender retningen om: System A sender en besked til integrationen, når noget bestemt er sket.

Polling

Integrationen spørger med faste intervaller: "Er der kommet nye eller ændrede data siden sidst?"

Batch eller import

Data flyttes i grupper - eksempelvis en natlig synkronisering eller filimport.

Ingen model er generelt bedst. Valget afhænger af timing, datamængde, API-muligheder og hvor robust driften skal være.

Realtime er ikke altid bedst

Realtime kan være vigtigt ved betaling, kritisk ordrestatus eller lagerinformation, hvor få minutters forsinkelse har reel konsekvens.

Det er mindre vigtigt ved eksempelvis natlig rapportering eller interne data, som kun ændres nogle få gange om dagen.

Realtime kan øge kravene til:

• monitoring
• event ordering
• retries
• dublethåndtering
• køer
• fejlalarmer

Vælg derfor synkroniseringsfrekvens ud fra forretningsbehovet - ikke fordi "realtime" lyder teknisk bedre.

Webhooks: hvordan virker de?

Et simpelt webhook-flow kan være:

1. En ordre oprettes i System A.
2. System A sender et event til integrationens webhook-URL.
3. Integrationen validerer afsenderen og payloaden.
4. Handlingen udføres i System B.
5. Eventets ID gemmes eller logges.

Webhooks bør designes med mulighed for, at events kan blive leveret igen. Hvis samme ordre-event behandles to gange, bør integrationen kunne genkende det og undgå at oprette to ordrer.

Signaturer, tokens eller andre mekanismer kan bruges til at kontrollere, at webhooket kommer fra den forventede afsender, afhængigt af systemets dokumentation.

Fejl er en del af integrationsdesignet

En integration, der kun virker i happy path, er ikke færdig.

Realistiske fejl omfatter:

• timeout
• API'et er nede
• 401 eller 403
• 429 rate limit
• 5xx serverfejl
• ugyldig payload
• ændret dataformat
• manglende felt
• dublet
• manglende mapping

For hver vigtig fejl bør man spørge:

Skal vi prøve igen, stoppe, varsle nogen eller sende posten til manuel behandling?

Det er ofte denne del, der afgør, om integrationen kan fungere stabilt i drift.

Retry: hvornår skal man prøve igen?

Nogle fejl er midlertidige. Et timeout eller en midlertidig 503 kan forsvinde ved næste forsøg. En 429 fortæller typisk, at klienten har sendt for mange requests og bør respektere API'ets rate-limit-adfærd.

Andre fejl bør normalt ikke bare retryes igen og igen:

• ugyldige data
• manglende rettighed
• ukendt kunde
• felt der ikke længere findes

Ved midlertidige fejl bruges ofte exponential backoff: næste forsøg venter længere end det forrige, så integrationen ikke angriber et presset API med endnu flere requests.

Idempotency: sådan undgår man dubletter

Forestil jer, at integrationen sender en ordre og derefter får timeout. Den ved nu ikke, om økonomisystemet nåede at oprette ordren før forbindelsen forsvandt.

Hvis den bare sender samme request igen, kan der opstå en dublet.

En robust integration kan blandt andet bruge:

• idempotency key
• eksternt reference-ID
• opslag før oprettelse
• deduplication-logik

Idempotency betyder praktisk, at det samme logiske forsøg ikke bør skabe flere forretningsmæssige resultater, bare fordi requestet måtte sendes igen.

Rate limits

Mange API'er begrænser, hvor mange requests en klient må sende over tid.

Det påvirker:

• hvor ofte data kan synkroniseres
• hvor store batches bør være
• hvordan retries planlægges
• om der skal bruges kø
• hvor hurtigt historiske data kan migreres

Rate limits skal læses i det konkrete APIs dokumentation. De bør ikke gættes.

Pagination

Et API returnerer ofte data i sider eller batches i stedet for alt på én gang.

En integration skal derfor kunne hente næste side, indtil datasættet er færdigt.

Typiske fejl er:

• kun første side importeres
• cursor/page-token håndteres forkert
• poster springes over
• data ændres under en lang pagination

Ved store datasæt bør pagination og sync-strategi testes med realistiske mængder.

Autentificering og adgang

API'er kan bruge forskellige adgangsmodeller, eksempelvis:

• API keys
• OAuth
• access tokens
• service accounts

Hovedprincippet bør være least privilege: integrationen får kun de rettigheder, den faktisk behøver.

Derudover bør:

• secrets ikke hardcodes i frontend-kode
• credentials kunne roteres
• test og production adskilles
• tokens behandles som følsomme credentials
• adgang fjernes, når integrationen ikke længere bruges

Ved OAuth bør scopes begrænses til de nødvendige ressourcer og handlinger.

Persondata og GDPR

Hvis integrationen flytter personoplysninger, bør databeskyttelse være en del af designet - ikke et punkt efter lancering.

Praktiske spørgsmål er blandt andet:

• Hvilke persondata er faktisk nødvendige?
• Hvem er dataansvarlig og eventuel databehandler?
• Hvem har adgang?
• Hvor længe skal data og logs opbevares?
• Hvilke systemer og underleverandører modtager data?
• Indeholder logs følsomme payloads?

Flyt kun de data, processen har brug for, og undgå at logge passwords, tokens eller komplette følsomme payloads uden et klart behov.

Det juridiske ansvar afhænger af den konkrete behandling og bør vurderes særskilt. Denne guide er teknisk beslutningshjælp, ikke juridisk rådgivning.

Logging: hvad skal integrationen kunne fortælle?

Når noget fejler, bør man kunne svare på:

• Hvad skete?
• Hvornår skete det?
• Hvilket system var involveret?
• Hvilken operation blev forsøgt?
• Lykkedes den?
• Hvilket reference-ID var involveret?
• Hvad var fejlen?

Logs skal være nyttige uden at blive en kopi af alle følsomme data.

Et godt reference-ID gør det muligt at følge samme kunde, ordre eller event gennem flere trin uden at gemme mere persondata end nødvendigt.

Monitoring og alarmer

En integration kan godt "køre", selv om den reelt er defekt.

Eksempel: Et natligt job starter hver dag, men alle requests bliver afvist på grund af udløbet adgang. Hvis ingen overvåger resultatet, kan fejlen stå i dagevis.

Monitoring bør kunne opdage eksempelvis:

• stigende fejlrate
• jobs der ikke kører
• voksende kø
• authentication failures
• rate limits
• forsinket synkronisering
• gentagne permanente fejl

Der skal også være en ejer, som faktisk reagerer på alarmerne.

API-versioner og ændringer

Tredjeparts-API'er ændrer sig.

De kan:

• tilføje eller ændre felter
• ændre authentication
• deprecate endpoints
• introducere en ny version
• ændre rate limits eller valideringsregler

Derfor er en integration ikke "byg én gang og glem".

Dokumentation, overvågning og ansvar for fremtidige ændringer bør være en del af driftsplanen.

Testmiljø og sandbox

Et testmiljø er værdifuldt, fordi integrationen kan afprøves uden at:

• oprette rigtige fakturaer
• sende mails til kunder
• ændre produktionsdata
• oprette falske live-ordrer

Ikke alle API'er tilbyder en god sandbox. Det bør undersøges tidligt, fordi manglende testmuligheder påvirker både scope og risiko.

Sådan scopes den første integration

Start med ét dataflow.

Eksempel:

Når kunde bliver vundet i CRM -> opret kunde i økonomisystem

Definér:

• trigger
• source
• destination
• felter
• dataejerskab
• mapping
• validering
• sync-frekvens
• fejlscenarier
• retries
• logging
• monitoring
• succeskriterie

Først derefter giver et estimat et ansvarligt beslutningsgrundlag.

10 fejlscenarier der bør være kendt før udvikling

1. API'et svarer ikke.
2. Access token er udløbet.
3. Kunden findes allerede.
4. Et obligatorisk felt mangler.
5. Rate limit er nået.
6. Destinationen returnerer 5xx.
7. Et webhook-event leveres to gange.
8. Dataformat eller felt ændres.
9. Destinationen afviser data permanent.
10. Et batch stopper midt i behandlingen.

Man behøver ikke forudsige alle tænkelige fejl. Men de mest sandsynlige failure modes bør have en kendt håndtering.

Native integration, automation-platform eller custom API-integration?

Det er ofte en fejl at springe direkte til custom kode. Hvis en native integration løser behovet robust, er den normalt værd at afprøve først.

API-integration vs. automatisering

Automatisering er det bredere begreb. API-integration er én teknisk metode, der ofte indgår i automatiseringen.

Eksempel:

Når status ændres i CRM -> send data til økonomisystem -> opret opgave -> varsling til medarbejder

API'erne forbinder systemerne. Automatiseringen beskriver hele arbejdsprocessen.

Hvis behovet primært handler om at fjerne gentagne manuelle trin, kan det derfor være relevant først at vurdere automatisering af arbejdsprocesser.

API-integration vs. internt system

En integration flytter eller koordinerer data mellem eksisterende systemer.

Et internt system giver medarbejderne en brugerflade, roller og en konkret arbejdsproces.

De to bruges ofte sammen:

CRM -> integration -> internt dashboard

Integrationen flytter data. Dashboardet gør dem anvendelige i arbejdet.

API-integration vs. custom webapp

En custom webapplikation kan bruge integrationer til CRM, betaling, økonomi, ERP, e-mail eller andre datakilder.

API-integrationen er dermed ofte én komponent i en større løsning - ikke selve slutproduktet.

Et integrationsflow fra CRM til økonomisystem

Et mere komplet flow kan være:

1. En trigger registrerer, at kunden er klar til overførsel.
2. Integrationen henter nødvendige data.
3. Data valideres.
4. Felter mappes til destinationens model.
5. Der kontrolleres for eksisterende kunde.
6. Integrationen autentificerer sig mod destinationen.
7. Data sendes.
8. Svaret kontrolleres.
9. Eksternt ID gemmes.
10. Resultatet logges.
11. Midlertidige fejl forsøges igen.
12. Permanente fejl udløser en alarm eller manuel opgave.

Når de 12 trin er beskrevet, er det langt lettere at vurdere både kompleksitet og risiko end ved blot at tælle endpoints.

Hvad påvirker kompleksiteten?

Kompleksitet afhænger blandt andet af:

• antal systemer og endpoints
• antal datafelter
• sync-retning
• datamapping
• datakvalitet
• API-dokumentation
• authentication
• testmiljø
• realtime-krav
• historiske data
• fejlhåndtering
• monitoring
• rate limits
• pagination
• webhooks
• sikkerhed
• løbende vedligehold

Derfor bør et konkret API-integrationsprojekt først estimeres, når dataflow og API-adgang er undersøgt. Artiklen her bør ikke fungere som en generel prisguide.

Hvad bør virksomheden have klar før et estimat?

• systemerne der skal forbindes
• API-dokumentation
• adgangstype
• sandbox/testmiljø
• relevante endpoints
• datafelter
• source of truth
• sync-retning
• ønsket frekvens
• kendte fejlscenarier
• realtime-behov
• forventet datamængde
• ansvarlig systemejer

Hvis flere af punkterne stadig er ukendte, bør første leverance være teknisk afklaring frem for et stort udviklingsscope.

Sådan vurderer du, om API-integration er næste skridt

En integration er værd at undersøge, hvis:

• samme data tastes i flere systemer
• manuelle exports/imports er tilbagevendende
• data skal være konsistente på tværs
• et website eller en webapp mangler data fra et eksisterende system
• kunder skal se data fra bagvedliggende systemer
• et workflow stopper, fordi systemer ikke kommunikerer
• processen er stabil og veldefineret
• der findes brugbar API-adgang

Overvej noget enklere, hvis:

• opgaven sker sjældent
• en native integration allerede løser den
• datakvaliteten er dårlig
• processen endnu ikke er stabil
• realtime ikke skaber reel værdi
• API'et ikke understøtter workflowet

En API-integration er ikke færdig ved launch

Efter lancering bør der være en plan for:

• monitoring
• fejlalarmer
• credentials og rotation
• API-versioner
• dokumentation
• ansvar
• test ved ændringer
• tredjeparts-deprecations

En integration har eksterne afhængigheder. Det skal afspejles i driften.

En god integration starter derfor ikke med at vælge endpoint. Den starter med at definere dataejerskab, flow, fejlscenarier og hvad virksomheden faktisk prøver at forbedre.

Hvis processen er klar, men den tekniske forbindelse mellem systemerne mangler, kan AS Web Solutions hjælpe med at afklare API-adgang, dataflow og en realistisk første version.

FAQ

Hvad er en API-integration?

En API-integration er softwarelogik, der bruger et eller flere API'er til at flytte eller behandle data mellem systemer efter definerede regler.

Hvad er forskellen på API og integration?

API'et er systemets tekniske grænseflade. Integrationen er den konkrete løsning, der bruger API'et til et bestemt dataflow eller workflow.

Hvad er forskellen på API og webhook?

Et API bruges ofte ved, at integrationen aktivt sender eller henter data. En webhook bruges typisk til, at et system sender besked, når en hændelse er sket.

Skal en integration være realtime?

Nej. Realtime giver kun mening, når forretningen har brug for meget hurtig opdatering. Batch eller planlagt sync kan være enklere og mere robust.

Hvad sker der, hvis et API går ned?

Integrationen bør have timeouts, logs og en plan for midlertidige fejl. Nogle operationer kan retryes sikkert, mens andre kræver manuel håndtering.

Kan to systemer synkronisere begge veje?

Ja, men tovejssync kræver klare regler for konflikter, dataejerskab og samtidige ændringer. Envejssync er ofte enklere.

Hvad er en API-nøgle?

En API-nøgle er en credential, som et system kan bruge til at identificere eller autorisere en klient. Den skal behandles som en hemmelighed og må ikke eksponeres ukritisk.

Kan en integration skabe dubletter?

Ja, især ved retries eller gentagne events. Eksterne reference-IDs, idempotency og deduplication-logik kan reducere risikoen.

Kan et API integreres med CRM eller økonomisystem?

Det afhænger af det konkrete systems API, adgangsmodel og de nødvendige endpoints. Et API kan eksistere uden at understøtte netop det ønskede workflow.

Hvad skal være klar før et integrationsprojekt?

Som minimum: de to systemer, ønsket dataflow, API-dokumentation, relevante felter, source of truth, sync-retning, timing, testadgang og centrale fejlscenarier.