Integrationer & API'er

Hvis disse spørgsmål ikke er afklaret, kan selv en teknisk korrekt integration skabe problemer. Data kan blive overskrevet i den forkerte retning, dubletter kan opstå, eller medarbejdere kan miste tilliden til systemet. Derfor bør dataflowet beskrives, før udviklingen begynder.

Hvad er en systemintegration?

En systemintegration er en teknisk forbindelse, der gør det muligt for to eller flere systemer at udveksle data eller udløse handlinger. Formålet er typisk at reducere manuelt arbejde, skabe mere ensartede data og gøre en arbejdsgang mindre afhængig af, at en medarbejder husker hvert enkelt trin. En integration kan eksempelvis sørge for, at:

• En webshopordre oprettes i økonomisystemet
• En betaling opdaterer ordrestatus
• Et CRM-system modtager en ny kundehenvendelse
• Et lager opdaterer beholdningen i webshoppen
• En fragtplatform modtager ordredata
• Et internt system henter priser eller produktdata
• En formular opretter en sag i et supportsystem
• Et regneark importeres til en database
• En ekstern tjeneste modtager en webhook

Integrationer kan være små og afgrænsede eller indgå i en større arkitektur med mange systemer. Kompleksiteten afhænger ikke kun af antallet af systemer, men også af datamængde, forretningsregler, fejlscenarier og krav til aktualitet.

Der findes ikke én integrationsmetode, der altid er den rigtige. Valget afhænger af systemernes muligheder, datamængde, hastighed, sikkerhed, stabilitet og vedligeholdelse.

REST API

REST API’er er en af de mest almindelige måder at forbinde moderne systemer på. Data udveksles typisk som JSON over HTTP, og handlinger organiseres omkring ressourcer som kunder, ordrer, produkter eller fakturaer. En REST-integration kan eksempelvis hente en ordre med GET, oprette en kunde med POST, opdatere et produkt med PATCH eller PUT og slette en afgrænset ressource med DELETE. REST er ofte et godt valg, fordi teknologien er udbredt og relativt let at dokumentere. Men en stabil integration kræver stadig håndtering af autentifikation, paginering, rate limits, timeout, versionsændringer og fejlstatusser.

GraphQL

GraphQL giver klienten mulighed for at specificere præcis, hvilke felter og relationer der ønskes. Det kan være en fordel, hvis et system har komplekse data, og en REST-løsning ellers ville kræve mange separate kald. GraphQL kan reducere over- og underhentning af data, men stiller krav til forståelse af schema, queries, mutations, felttyper og fejlformat. GraphQL er ikke automatisk bedre end REST — det er et alternativ, der giver mening, når systemets API og dataform understøtter det.

Webhooks

En webhook er en besked fra ét system til et andet, når en bestemt hændelse sker. I stedet for at spørge hvert femte minut, om der er kommet en ny ordre, kan webshoppen sende besked med det samme — eksempelvis ved ordre oprettet, betaling gennemført, abonnement fornyet, kunde opdateret eller lager ændret. Webhooks kræver stærk modtagelse: endpointet skal validere afsenderen, håndtere gentagne leverancer og svare hurtigt. Den tunge behandling bør ofte lægges i en kø, så afsenderen ikke oplever timeout.

Fladfilsudveksling

Fladfiler er fortsat relevante. Mange økonomi-, lager-, produktions- og branchesystemer kan eksportere eller importere CSV, XML, JSON eller Excel, selv om de ikke har et moderne API. Et filflow kan eksempelvis være:

1. System A eksporterer en CSV-fil hver nat
2. Filen placeres på SFTP
3. Integrationen henter filen
4. Data valideres og transformeres
5. Gyldige rækker importeres i system B
6. Fejlrapport gemmes eller sendes
7. Filen arkiveres med status

Filudveksling kan være stabil og økonomisk fornuftig, når realtid ikke er nødvendigt. Den kræver dog klare regler for filnavne, encoding, separatorer, datoformater, decimaler, tomme værdier, versionsændringer og dubletter.

EDI

EDI bruges ofte mellem virksomheder til ordrer, fakturaer, leverancer og lagerbeskeder. Det kan være baseret på standarder eller leverandørspecifikke formater. EDI kan være robust i etablerede værdikæder, men kræver præcis mapping og aftale om meddelelsestyper, felter og kvitteringer. Det er sjældent noget, man bare aktiverer uden teknisk og forretningsmæssig afklaring.

Databaseintegrationer

Direkte databaseadgang kan i nogle interne miljøer være relevant, men bør bruges med forsigtighed. En database er ofte en intern implementeringsdetalje og ikke en stabil offentlig kontrakt. Hvis et system opdateres, kan tabeller eller relationer ændre sig, og direkte skrivning kan omgå forretningsregler, validering og audit logs. Derfor bør et officielt API foretrækkes, når det findes.

Message queues og asynkron behandling

Ved større datamængder eller kritiske flows kan beskeder lægges i en kø. Det betyder, at modtagelse og behandling adskilles, så midlertidige fejl kan håndteres med genforsøg, belastning kan fordeles, afsenderen ikke behøver vente, og fejlede beskeder kan placeres i en dead-letter queue. Købaserede løsninger kræver mere drift og overvågning, men kan være den rigtige arkitektur, når integrationen er forretningskritisk eller har mange hændelser.

Scraping — kun når der ikke findes en bedre adgang

Scraping betyder, at data hentes fra en hjemmeside eller brugerflade frem for gennem et officielt API eller en eksportfunktion. Teknisk kan scraping være muligt, men det bør normalt være en sidste udvej. HTML-struktur, loginflow, botbeskyttelse eller feltnavne kan ændres uden varsel, og det gør løsningen mere skrøbelig end en officiel integration. Før scraping overvejes, bør man afklare, om der findes et API, en eksport eller filudveksling, om leverandøren kan give adgang, og om vilkår og lovgivning tillader dataindsamlingen — særligt hvis persondata eller ophavsretligt indhold er involveret.

Data skal være struktureret korrekt

En integration kan ikke gøre uklare data entydige uden regler. Hvis samme kunde findes med tre forskellige navne, eller produkter mangler et stabilt varenummer, skal dataforholdet afklares. Vigtige spørgsmål:

• Hvilke felter findes i begge systemer?
• Hvilke felter skal transformeres?
• Hvilke værdier er obligatoriske?
• Hvordan håndteres null, tom tekst og manglende felter?
• Hvilket dato- og tidsformat bruges, og hvilken tidszone gælder?
• Hvordan repræsenteres valuta og decimaler?
• Hvordan identificeres den samme kunde eller ordre?
• Er der referencer mellem dataobjekter?
• Hvilke værdier skal mappes mellem systemerne?

Et eksempel: Et system bruger ordrestatus “paid”, mens et andet bruger “2” eller “Betalt”. Integrationen skal have en tydelig mapping og kende konsekvensen, hvis en ukendt status modtages.

Hvilket system er master?

For hvert dataområde bør der være et system, som betragtes som den autoritative kilde. Webshoppen ejer måske ordredata, økonomisystemet ejer bogføringsstatus, lageret ejer beholdningen, CRM ejer salgsnoter, og et PIM ejer produkttekster og billeder. Hvis begge systemer frit må overskrive de samme oplysninger, kan der opstå konflikter. Derfor skal det beskrives, hvilke systemer der må oprette, opdatere og slette data.

Dataflow — hvordan skal oplysningerne flyde?

Dataflowet bør beskrives visuelt eller i en tabel før udvikling. Det skal fremgå, hvad der starter flowet, hvilke systemer der er involveret, hvilke data der sendes, hvilke transformationer og valideringer der udføres, hvilket system der opdateres, hvad der returneres, og hvad der sker ved fejl. Et eksempel:

1. En kunde gennemfører en ordre i WooCommerce
2. WooCommerce sender en webhook
3. Integrationen validerer signatur og ordre-ID
4. Ordren lægges i en kø
5. Kunden slås op i e-conomic
6. Kunde oprettes eller matches
7. Varelinjer mappes til produkter og konti
8. En fakturakladde oprettes
9. Eksternt ID gemmes på WooCommerce-ordren
10. Resultat logges
11. Ved fejl oprettes alarm, og opgaven kan genkøres

Envejs- eller tovejssynkronisering?

Envejssynkronisering er ofte enklere og mere robust. Data flyder fra master-systemet til modtageren. Tovejssynkronisering kan være nødvendig, men skaber flere spørgsmål:

• Hvad sker der, hvis begge systemer ændrer samme felt?
• Hvilken ændring vinder?
• Hvordan sammenlignes tidspunkter?
• Kan en opdatering skabe en uendelig løkke?
• Hvordan spores kilden til ændringen?

Tovejssynkronisering bør ikke vælges alene, fordi det lyder fleksibelt. Den skal have en konkret forretningsmæssig grund.

Real-time, near real-time eller batch?

Ikke alle data behøver flyttes med det samme. Real-time er relevant for betaling, checkout, adgangsstyring eller hændelser, der kræver hurtig reaktion. Near real-time behandles typisk inden for sekunder eller minutter via kø eller planlagte jobs. Batch flytter data samlet hver time, nat eller uge og kan være tilstrækkeligt for produktfeeds, rapportering eller økonomiske udtræk. Hurtigere er ikke altid bedre — real-time øger ofte kompleksitet og krav til tilgængelighed.

Stærk fejlhåndtering er en del af integrationen

Alle eksterne systemer kan fejle. API’et kan være nede, adgangstoken kan udløbe, data kan være ugyldige, eller rate limits kan blive nået. En robust integration bør tage højde for timeout, netværksfejl, 4xx- og 5xx-fejl, ugyldig autentifikation, rate limiting, manglende felter, ukendte værdier, dubletter, delvist gennemførte flows og ændringer i API-version.

Logning

Logning skal gøre det muligt at svare på, hvilken hændelse der blev modtaget, hvornår det skete, hvilke systemer der var involveret, hvilken intern og ekstern nøgle der blev brugt, om behandlingen blev gennemført, og hvilken fejl der ellers opstod. Logs bør ikke ukritisk gemme adgangskoder, tokens eller unødvendige persondata.

Retries og backoff

Midlertidige fejl kan ofte løses ved automatisk genforsøg. Men integrationen bør ikke sende hundredvis af hurtige gentagelser til et system, der er nede. En løsning kan bruge eksponentiel backoff og et begrænset antal retries. Permanente valideringsfejl bør normalt ikke genkøres automatisk uden ændring af data.

Idempotens og dubletter

Idempotens betyder, at den samme hændelse kan behandles igen uden at skabe et nyt uønsket resultat. Hvis en webhook leveres to gange, bør integrationen ikke oprette to fakturaer. Det kræver stabile nøgler, status eller idempotency keys.

Dead-letter queue og manuel behandling

Når en opgave ikke kan gennemføres efter flere forsøg, bør den ikke bare forsvinde. Den kan placeres i en separat fejlkø med årsag og relevante data, så den kan undersøges og genkøres.

Alarmer og ansvar

Det bør være aftalt, hvem der får besked ved fejl. Ikke alle fejl kræver en SMS klokken tre om natten, men kritiske betalings- eller ordreflows kan kræve hurtig reaktion. Alarmer kan opdeles efter alvor: info, advarsel, fejl og kritisk.

Sikkerhed og adgang

Integrationer arbejder ofte med følsomme forretningsdata og personoplysninger. Adgang bør begrænses til det nødvendige. Det kan omfatte:

• OAuth 2.0
• API-nøgler
• Signerede webhooks
• IP-begrænsning
• Servicekonti
• Krypteret transport
• Secret management
• Rotering af credentials
• Begrænsede scopes
• Audit logs

Adgangskoder og tokens bør ikke hardcodes i offentlig kode eller sendes ukrypteret i almindelige mails.

API-versioner og vedligeholdelse

Et API er ikke nødvendigvis statisk. Leverandører kan udfase versioner, ændre felter eller justere begrænsninger. En integration bør derfor have en kendt API-version, dokumenterede afhængigheder, overvågning af fejl, en plan for opdatering, et testmiljø hvor det findes, og kontakt til systemejer eller leverandør. En integration er ikke en engangsfil, der aldrig skal ses igen — kritiske koblinger bør vedligeholdes.

Standardintegration eller specialudvikling?

En eksisterende standardintegration bør vurderes først. Den kan være billigere, hurtigere og vedligeholdt af leverandøren. Specialudvikling kan være relevant, når standardløsningen mangler nødvendige felter, dataflowet er virksomhedsspecifikt, flere systemer skal kobles, der kræves særlig validering, fejlhåndtering og logning er utilstrækkelig, licensmodellen er uhensigtsmæssig, eller integrationen skal indgå i et større internt system.

API-udvikling til egne systemer

Nogle virksomheder har et internt system, der skal kunne bruges af en app, webshop, partner eller anden tjeneste. Her kan der udvikles et API som en stabil grænseflade. Et API bør blandt andet beskrive ressourcer og endpoints, request- og responseformat, felttyper, valideringsregler, autentifikation, rettigheder, fejlstatusser, paginering, rate limits, versionsstrategi og dokumentation. Et API skal ikke blot eksponere databasen direkte — det bør beskytte forretningsregler og begrænse adgangen til det nødvendige.

Typiske integrationer jeg kan hjælpe med

Muligheden afhænger altid af de konkrete systemers dokumentation, adgang og vilkår, men typiske opgaver er blandt andet:

• WooCommerce til e-conomic, Dinero eller Uniconta
• WordPress til CRM
• Formular til supportsystem
• Betaling til ordrestatus
• Ordre til fragtlabel
• Lager til webshop
• Produktdata til webshop
• Medlemssystem til adgangsstyring
• Specialsystem til økonomi
• Laravel-system til tredjeparts-API
• CSV/XML-import og eksport
• Webhooks mellem SaaS-systemer

Et konkret eksempel har jeg beskrevet i guiden om integration mellem webshop og økonomisystem, hvor fordele og typiske faldgruber gennemgås. WordPress og WooCommerce har både REST API, webhooks, hooks og pluginmuligheder; den tekniske udvikling behandles på siderne om WordPress-udvikling og WooCommerce-udvikling. Laravel og andre frameworks kan fungere som datakilde, modtager og integrationslag under specialudvikling i Laravel.

Hvad koster en API-integration?

Prisen afhænger af systemerne og dataflowet. En enkel integration med veldokumenterede API’er kan være relativt afgrænset. En tovejssynkronisering med mange objekter, mangelfuld datakvalitet og komplekse fejlscenarier kræver mere analyse og test. Prisen påvirkes blandt andet af:

• Antal systemer
• API-kvalitet og dokumentation
• Autentifikationsform
• Antal dataobjekter
• Envejs- eller tovejssynkronisering
• Realtid eller batch
• Datamapping og transformation
• Mængden af historiske data
• Fejlhåndtering og overvågning
• Testmiljøer
• Sikkerhedskrav
• Dokumentation samt drift og vedligeholdelse

Ved ukendte systemer kan opgaven begynde med en betalt analyse eller et proof of concept. Jeg giver ikke en fast pris uden at kende systemerne, men omfang og forudsætninger beskrives, før arbejdet begynder.

Hvorfor arbejde direkte med en freelance API-udvikler?

Du har direkte kontakt til den person, der analyserer og udvikler integrationen. Det reducerer risikoen for, at tekniske detaljer går tabt mellem salg, projektledelse og udvikling.

Jeg arbejder med WordPress, WooCommerce, Laravel, økonomisystemer, betaling, fragt, automatisering og API’er. Det gør det muligt at vurdere integrationen i sammenhæng med de berørte arbejdsgange. Ved komplekse ERP-, sikkerheds-, juridiske eller regnskabsmæssige forhold kan relevante specialister eller systemleverandører være nødvendige. Du kan læse mere om mig og se udvalgte cases.