Meny

Generell forklaring av Public API

Public Admin API Module er et grensesnitt som lar eksterne systemer kommunisere med nettbutikken og lager-/logistikkløsningen din. Med en API-nøkkel kan tredjepartssystemer – for eksempel regnskap, ERP, PIM, BI-verktøy, egne portaler eller integrasjonsplattformer – lese og skrive data direkte mot butikken din, uten å gå via brukergrensesnittet.

Se også hvordan du Oppretter en API-Nøkkel.

 


 

Hva kan du bruke API-et til?

API-et er bygget for administrativ integrasjon – altså flyt av forretningsdata mellom systemene dine. Typiske bruksområder:

  • Ordre og fakturering: hente ordrer, ordrelinjer og leveranser inn i regnskap eller ERP, og oppdatere status tilbake.

  • Kunder: synkronisere kunder og kundegrupper mellom CRM og butikk.

  • Produkter og lager: opprette og oppdatere produkter, priser, plasseringer, lagerbeholdning og lagerjusteringer fra et PIM- eller ERP-system.

  • Innkjøp og leverandører: opprette og følge opp innkjøpsordrer, leverandørprodukter og lageroverføringer.

  • Kampanjer: styre kuponger, rabatter og tilbud automatisk.

  • Innhold: vedlikeholde mapper, kategorier, bilder, filer, blogginnlegg og relasjoner i innholdsarkivet.

  • Webhooks: la eksterne systemer få beskjed automatisk når noe endrer seg, i stedet for å måtte spørre hele tiden.

  • Rapportering: hente ut salgsrapporter og produkthistorikk til BI-verktøy.

 

Fordeler

  • Automatisering: kutter manuelt dobbeltarbeid mellom butikken og andre systemer.

  • Standardisert og forutsigbart: følger anerkjente REST-prinsipper, slik at de fleste integrasjonsleverandører kjenner mønsteret igjen.

  • Sikker tilgang: hver integrasjon får sin egen API-nøkkel med tokenbasert pålogging, og tokenet utløper jevnlig.

  • Selektiv datahenting: du kan be om akkurat de feltene og relasjonene du trenger, slik at integrasjonene blir raske og lette.

  • Kraftig søk og filtrering: data kan hentes ut med sortering, paginering og filtrering, så store kataloger kan synkroniseres effektivt.

  • Hendelsesdrevet flyt: webhooks gjør at andre systemer kan reagere umiddelbart på endringer, framfor å polle.

  • Interaktiv dokumentasjon: en innebygd Swagger-side beskriver alle endepunkter og lar utviklere prøve dem i nettleseren.

 

Hva API-et ikke skal brukes til

Public Admin API er ment for administrasjon og dataintegrasjon – ikke for å betjene besøkende i nettbutikken. Bruk derfor ikke API-et til:

  • Innholdsleveranse til sluttbrukere. API-et skal ikke brukes til å levere produktlister, bilder, priser, kategorisider eller annet innhold direkte til besøkende i nettbutikken eller til en frontend som vises for sluttkunder. Innhold til kunder leveres av selve nettbutikken; integrasjonens jobb er å holde dataene oppdatert, ikke å vise dem.

  • Storstilt henting av mediefiler. API-et er ikke et CDN. Bilder og filer skal lastes inn én gang og deretter gjenbrukes fra butikkens egne URL-er, ikke pumpes ut til sluttbrukere via API-et.

  • Anonyme eller offentlige kall. Alle nyttige endepunkter krever gyldig API-nøkkel. API-et er ikke åpent for besøkende eller upålogget trafikk.

  • Sanntids-polling i høyt tempo. For å reagere på endringer skal du bruke webhooks, ikke spørre API-et flere ganger i sekundet.

 

Begrensninger og kvoter

For å beskytte butikken og sikre rettferdig bruk for alle som integrerer, har API-et innebygde grenser. Grensene gjelder per API-nøkkel og per endepunkt:

Tidsvindu for Maks antall forespørsler

Per sekund: 5

Per minutt: 100

Per time: 2 000

Per døgn: 30 000

Enkelte endepunkter har egne, strammere grenser. Innloggings­endepunktet (/token) er for eksempel begrenset til 2 kall per sekund og 100 per time for å hindre misbruk.

Merk: Vi forbeholder oss retten til å justere disse grensene – både opp og ned, generelt eller per integrasjon – uten forhåndsvarsel, dersom det er nødvendig for å beskytte stabiliteten og ytelsen i tjenesten. Integrasjoner bør derfor alltid håndtere 429-svar på en robust måte, og ikke anta at dagens tall står fast.

Andre praktiske grenser:

  • Maks 1 000 elementer per listekall. Større datamengder må hentes med paginering.

  • Tokenet utløper. Et innloggingstoken er som standard gyldig i 60 minutter, og integrasjonen må be om et nytt etterpå.

  • For mange kall gir 429-svar. Når grensen er nådd, blir kallene avvist med en melding om hvor lenge man må vente før neste forsøk.

  • Funksjonelle begrensninger. Endringer som er sperret i selve butikken (for eksempel kunder uten obligatoriske felt eller ordre i låst status) er også sperret via API-et – API-et følger de samme forretningsreglene som administrasjons­grensesnittet.

 

Sikkerhet

  • Hver integrasjon får en egen API-nøkkel (client-ID og hemmelighet).

  • Pålogging skjer ved å bytte API-nøkkelen mot et tidsbegrenset token, som sendes med på hvert kall.

  • Bruken loggføres, og uvanlig aktivitet kan oppdages og blokkeres.

  • Rettighetene følger den brukeren som API-nøkkelen er knyttet til.

 

Når passer API-et – og når passer det ikke?

Passer godt til

- Synkronisering av ordre, kunder, produkter, lager og innkjøp mellom butikk og ERP/CRM/PIM

- Automatiske jobber som kjører jevnlig (for eksempel hver natt eller hvert kvarter)

- Hendelsesdrevne flyter via webhooks

- Egne rapporter, dashbord og BI-uthentinger

 

Passer dårlig til

- Levering av produktsider, kategorisider eller bilder til besøkende i nettbutikken

- Sanntids-oppslag som skjer mange ganger i sekundet per besøk

- Kontinuerlig polling for å oppdage endringer

- Offentlig tilgjengelige tjenester uten innlogging

"Er

Er du interessert i å vite mer?

Ta kontakt med oss på e-post.: support@netthandel.unimicro.no, eller skriv til oss via vårt
kontaktskjema. 

Kontakt oss