Gratis guide · arkitektur · interaktiv demonstrasjon
API-integrasjoner fra bunnen
En API-integrasjon flytter ikke bare data fra A til B. Den må forstå avsenderen, avvise feil, beskytte hemmeligheter, tåle gjentakelser og gjøre det mulig å finne ut hva som skjedde.
Denne guiden gir deg en produksjonsrettet grunnmodell og et lokalt API-laboratorium du kan prøve uten konto. Demonstrasjonen sender ikke data ut av nettleseren.
Grunnmodellen
En robust integrasjon har flere kontrollpunkter
→
→
→
→
Logging gjør hendelser sporbare
Timeout og retry håndterer midlertidige feil
Før du skriver kode
Avklar kontrakten mellom systemene
Start med en liten kontrakt som begge sider kan forstå. Den bør beskrive hendelsen, versjonen, en unik identifikator, tidspunktet og selve fagdataene.
{
"event": "customer.created",
"version": 1,
"id": "evt_20260919_001",
"occurred_at": "2026-09-19T10:15:00Z",
"data": {
"customer_id": "cus_1042",
"name": "Eksempelbedrift AS",
"email": "kontakt@example.no"
}
}Navn og versjon
event sier hva som skjedde. version gjør at kontrakten kan videreutvikles uten å gjette formatet.
Unik ID
id lar mottakeren kjenne igjen samme hendelse hvis avsenderen prøver på nytt.
Tid og fagdata
occurred_at beskriver når hendelsen skjedde. data inneholder bare det mottakeren trenger.
Bygg selv
Åtte steg fra idé til drift
-
01
Beskriv én konkret flyt
Skriv «Når X skjer i system A, skal Y opprettes eller oppdateres i system B». Skill nødvendige data fra data som bare er hyggelige å ha.
-
02
Velg retning og utløser
Bruk webhook når avsenderen kan varsle straks. Bruk planlagt henting når mottakeren må spørre eller kilden ikke tilbyr hendelser.
-
03
Beskytt tilgangen
Hold nøkler på serveren, bruk HTTPS, begrens rettigheter og roter hemmeligheter etter en plan. Legg aldri nøkler i nettleserkode eller offentlige repoer.
-
04
Valider før behandling
Kontroller innholdstype, størrelse, obligatoriske felt, typer og tillatte verdier. Avvis ugyldige data med et forståelig svar.
-
05
Gjør flyten idempotent
Lagre eller kontroller hendelses-ID slik at samme forespørsel ikke oppretter to kunder, ordrer eller betalinger.
-
06
Planlegg feil
Bruk korte timeouts, begrenset retry med økende ventetid og en kø eller manuell kontroll for hendelser som ikke lykkes.
-
07
Logg uten å lekke data
Logg korrelasjons-ID, status, varighet og feilkategori. Unngå passord, tokens og unødvendige personopplysninger.
-
08
Test og sett i drift kontrollert
Test gyldig data, ugyldig data, duplikat, timeout og utilgjengelig mottaker. Start begrenset og følg de første virkelige hendelsene.
Interaktiv demonstrasjon
Prøv dataflyten i API-laboratoriet
Velg et eksempel eller rediger JSON selv. Når du kjører simuleringen, valideres innholdet lokalt i nettleseren. Ingen forespørsel sendes til Finnandre eller en tredjepart.
Klar til å validere en lokal forespørsel
- 1
Les JSONIkke kjørt
- 2
AutentiseringSimulert nøkkel
- 3
Valider kontraktIkke kjørt
- 4
Kontroller duplikatIkke kjørt
- 5
Godta hendelseIkke kjørt
{
"status": "waiting"
}JavaScript er slått av. Du kan fortsatt bruke hele guiden, men den lokale demonstrasjonen krever JavaScript.
Dette er en simulering: Den demonstrerer kontrollrekkefølgen, men bruker ingen ekte API-nøkkel, database, kø eller ekstern mottaker. Produksjon krever serverkode, tilgangsstyring, overvåking og testing mot de faktiske systemene.
Minste produksjonssjekk
Kontroller dette før integrasjonen får virkelige data
- HTTPS og sertifikat er gyldig.
- Nøkler ligger utenfor kode og nettleser.
- Rettigheter er begrenset til nødvendig handling.
- Payload har størrelse- og skjemavalidering.
- Duplikater gir ikke dobbeltarbeid.
- Timeout og retry har klare grenser.
- Feil kan finnes uten å logge hemmeligheter.
- Varsling finnes for varige feil.
- Testmiljø og rollback er avklart.
- Eier, dokumentasjon og videre drift er tydelig.
Vanlige feil
Det som ofte ser ferdig ut, men ikke er det
«Det virker når jeg trykker én gang»
Det beviser bare normalflyten. Prøv samme hendelse to ganger, ugyldige data, sakte mottaker og full utilgjengelighet.
«Vi lagrer hele forespørselen for sikkerhets skyld»
Da kan logger bli en skjult kopi av personopplysninger og hemmeligheter. Logg identifikatorer og feilkategorier, ikke mer data enn feilsøkingen krever.
«Vi prøver bare på nytt til det virker»
Ubegrenset retry kan forsterke feil og lage duplikater. Bruk maksimalt antall forsøk, økende ventetid og en tydelig vei for manuell kontroll.
«API-nøkkelen kan ligge i JavaScript»
Nei. Kode som sendes til nettleseren er offentlig for brukeren. Hemmeligheter må ligge bak et kontrollert servergrensesnitt.
Eksempel på manuell kontroll
Test et endepunkt med en tydelig forespørsel
Når du har et eget testendepunkt, kan en forespørsel kontrolleres med et verktøy som curl. Bruk en testnøkkel og testdata – aldri produksjonshemmeligheter i delt terminalhistorikk eller dokumentasjon.
curl --request POST "https://api.example.no/v1/events" \
--header "Authorization: Bearer TEST_TOKEN" \
--header "Content-Type: application/json" \
--header "Idempotency-Key: evt_demo_001" \
--data @event.jsonEt godt svar bruker en passende HTTP-status og en maskinlesbar kropp. 202 Accepted passer når hendelsen er godkjent for senere behandling; 400 eller 422 passer ved ugyldige data; 401 eller 403 ved manglende tilgang.
Bruk guiden fritt
Vil du bygge selv eller få integrasjonen gjennomført?
Du kan bruke denne modellen uten å kjøpe noe. Hvis integrasjonen skal kobles til virkelige kunde-, ordre-, WordPress-, CRM-, regnskaps- eller IoT-systemer, kan Finnandre kartlegge grensesnittene og bygge en kontrollert første fase.