API og webhooks for nettbutikk

Et API for nettbutikk lar andre systemer lese eller endre data etter definerte regler. Webhooks sender beskjed når en hendelse skjer, for eksempel at en ordre er opprettet eller en betaling har endret status.

De brukes ofte sammen: webhooken varsler om hendelsen, og mottakeren bruker API-et til å hente oppdaterte detaljer. Når du sammenligner plattformer, bør du vurdere dokumentasjon og driftsegenskaper, ikke bare om ordene «åpent API» står i funksjonslisten.

API eller webhook?

En integrasjon bør tåle at en webhook kommer to ganger, i feil rekkefølge eller forsinket.

Ressurser nettbutikker ofte trenger

• produkter, varianter, priser og bilder
• lager per varenummer og lokasjon
• kunder og samtykkestatus
• ordre, varelinjer, rabatt, avgift og status
• betaling, oppgjør, retur og refusjon
• fraktvalg, forsendelse og sporingsnummer

Be om en ressurs- og feltoversikt. «Ordre-API» kan bety alt fra lesetilgang til full oppdatering, og felt som MVA, valuta eller delretur kan mangle.

Frakt-API for nettbutikk

En fraktintegrasjon må ofte håndtere mer enn å opprette etikett. Test hele løpet:

1. hent tilgjengelige tjenester ut fra adresse, vekt og mål
2. vis riktig leveringsvalg og pris i kassen
3. overfør ordren til lager eller transportør
4. motta forsendelses- og sporingsreferanse
5. oppdatere kunden uten duplikate meldinger
6. håndtere kansellering, flere kolli og del-levering
7. avstemme faktisk fraktkostnad mot det kunden betalte

Hvis transportørens API er nede, må kassen ha en kontrollert reserveflyt. Et teknisk problem skal ikke automatisk gi gratis eller umulig frakt.

Kravliste til et nettbutikk-API

Spør også om oppetid, supportkanal og varsling ved driftsavvik. En integrasjon uten navngitt eier hos hver part blir dyr når noe stopper.

Webhooks som tåler virkeligheten

Mottakeren bør kontrollere signatur eller annen autentisitet, lagre hendelses-ID, svare raskt og behandle jobben separat. Ved feil må hendelsen kunne forsøkes på nytt uten å skape duplikater.

God drift krever:

• logg over mottatt tidspunkt, type og hendelses-ID
• deduplisering
• kontroll med rekkefølge og siste kjente versjon
• kø og begrenset gjenkjøring
• varsel etter gjentatte feil
• manuell mulighet til å hente manglende data via API

Ikke logg komplette kunde- eller betalingsdata hvis det ikke er nødvendig for feilsøkingen.

Sikkerhet og personvern

Gi integrasjonen minste nødvendige tilgang. En fraktkobling trenger kanskje ordre- og adressedata, men ikke full kundehistorikk eller rett til å endre priser.

• bruk separate nøkler eller klienter per integrasjon og miljø
• oppbevar hemmeligheter i et sikkert system
• roter og tilbakekall tilgang ved behov
• valider input, også når avsenderen er kjent
• begrens persondata og lagringstid
• før spor over administrative endringer

Eksempel: ordre til regnskap

En robust flyt kan se slik ut:

1. ordre opprettet varsler integrasjonen
2. integrasjonen henter ordre og betalingsreferanse via API
3. regnskapsdata opprettes med samme eksterne ID
4. oppgjør kobles til betaling og bank
5. retur bruker opprinnelig ordre-ID og oppretter reversering
6. avvik havner i en synlig feilkø

Les Fiken-integrasjon for nettbutikk for kontrollpunktene i en konkret regnskapsflyt.

Før dere bygger selv

Sammenlign kostnaden ved ferdig kobling, integrasjonsplattform og egen kode. Ta med vedlikehold, overvåking, test ved API-endringer og beredskap når en leverandør er utilgjengelig.

Se alle integrasjoner , lagersystem-integrasjon og Zapier-integrasjon før dere velger arkitektur. Be alltid plattformleverandøren dokumentere de konkrete endepunktene og hendelsene dere trenger.