REST API

Oversikt

Shoporamas REST-API gir deg muligheten til å integrere nettbutikken din med eksterne systemer – ERP, lagerstyring, PIM, CRM og andre tjenester. API-et støtter CRUD (opprett, les, oppdater, slett) på de fleste ressursene i nettbutikken din.

Dokumentasjon

Den fullstendige API-dokumentasjonen med alle endepunkter, parametere og eksempler finner du i vår interaktive Swagger-dokumentasjon:

Åpne Swagger-dokumentasjonen

Her kan du teste API-kall direkte i nettleseren og se alle tilgjengelige felt og parametere for hver ressurs.

Kom i gang

1. Gå til Integrasjoner → API-tilgang i Shoporama-administrasjonen
2. Opprett en ny API-nøkkel
3. Velg rettigheter for nøkkelen: Alle, Kun lese eller Kun skrive. Rettigheten gjelder hele nøkkelen, ikke den enkelte ressursen
4. Bruk nøkkelen i Authorization-headeren på API-anropene dine

Autentisering

Legg til API-nøkkelen din i Authorization-headeren. Du kan enten sende nøkkelen direkte eller bruke Bearer-format:

Authorization: DIN-API-NØGLE

# Eller med Bearer:
Authorization: Bearer DIN-API-NØGLE

Tilgjengelige ressurser

API-et gir tilgang til følgende ressurser. Alle endepunkter er tilgjengelige på https://dinshop.dk/REST/:

Produkter og katalog

• /product — Produkter (med varianter, bilder, priser, kategorier, tilleggsfelt)
• /category — Kategorier
• /brand — Merker
• /manufacturer — Produsenter
• /supplier — Leverandører
• /product-label — Produktetiketter
• /profile, /profile-attribute, /profile-attribute-value — Produktprofiler, attributter og verdier

Lager

• /stock — Lagerbeholdning og posteringer
• /batch — Lagerpartier

Bestillinger og kunder

• /order — Ordrer
• /order/{id}/create-label — Opprett fraktetikett for ordre
• /order/{id}/download-label — Last ned fraktetikett
• /order-queue — Ordrekø
• /order-label — Ordrelabels
• /order-return — Returer
• /customer — Kunder
• /customer-field — Kundefelt
• /voucher — Rabattkoder og gavekort

Innhold

• /page — Statiske sider
• /blog-post — Blogginnlegg
• /landing-page og /landing-page-item — Landingssider og elementer. GET /landing-page/{id} returnerer nå sidens regler (rules) og match-type (match_type) direkte i svaret, slik at du slipper et separat kall til /landing-page-item
• /menu — Menyer og navigasjon

Nyhetsbrev

• /newsletter-list — Nyhetsbrevlister
• /newsletter-subscriber — Abonnenter
• /newsletter-campaign — Kampanjer

Innstillinger

• /shipping — Fraktmetoder
• /payment_gateway — Betalingsmetoder
• /country — Land
• /redirect — URL-viderekoblinger
• /webhook — Webhooks

Temafiler

• /theme-file — Les, opprett, oppdater og slett filer i temaene dine. Krever at «Tilgang til temafiler» er aktivert på API-nøkkelen

HTTP-metoder

• GET — Hent en liste eller en enkelt ressurs
• POST — Opprett en ny ressurs
• PUT — Oppdater en eksisterende ressurs
• DELETE — Slett en ressurs

Eksempler

Hent produkter:

curl -H "Authorization: DIN-API-NØGLE" \
  https://dinshop.dk/REST/product?limit=10

Opprett et produkt:

curl -X POST -H "Authorization: DIN-API-NØGLE" \
  -H "Content-Type: application/json" \
  -d '{"name": "Nytt produkt", "price": 199.00}' \
  https://dinshop.dk/REST/product

Oppdater lagerbeholdning:

curl -X PUT -H "Authorization: DIN-API-NØGLE" \
  -H "Content-Type: application/json" \
  -d '{"count": 50}' \
  https://dinshop.dk/REST/stock/123

Tallet i banen er produktets ID, og count er den nye samlede beholdningen.

Filtrering og paginering

Liste-endepunkter støtter følgende søkeparametere:

• ?limit=25 — antall resultater per side. Den øvre grensen avhenger av endepunktet (f.eks. 250 på /product), og fremgår av Swagger-dokumentasjonen
• ?offset=0 — hopp over resultater (for paginering)
• ?search=tekst — fritekstsøk
• ?fields=name,price — begrens antall felt som returneres
• ?last_modified=2026-01-01 — kun ressurser endret siden denne datoen

Webhooks

Du kan opprette webhooks via API-et, slik at systemet ditt automatisk får beskjed når det skjer endringer. Ved opprettelse mottar du en hemmelig nøkkel som brukes til å verifisere webhook-anrop via HMAC.

Svarkoder

• 200 — Vellykket
• 201 — Ressurs opprettet
• 204 — Oppdatering/sletting fullført
• 400 — Ugyldig forespørsel
• 401 — Ikke autorisert (feil eller manglende API-nøkkel)
• 403 — Nøkkelen er gyldig, men har ikke rettigheter til handlingen (f.eks. en nøkkel med «Kun lesing» som prøver å skrive)
• 404 — Ressursen ble ikke funnet
• 429 — For mange forespørsler (rate limit)

API-loggen: se hva som faktisk blir kalt

Hver API-nøkkel har sin egen logg over innkommende forespørsler. Dette er verktøyet du bør bruke når en integrasjon oppfører seg annerledes enn forventet, for loggen viser hva som faktisk traff nettbutikken din, ikke hva den eksterne leverandøren tror blir sendt.

Slik finner du loggen

1. Gå til Integrasjoner → API-tilgang
2. Finn nøkkelen i listen som integrasjonen bruker
3. Klikk på «Logg ut»-knappen for nøkkelen

Loggfilen tilhører alltid én bestemt nøkkel, og det finnes ikke en samlet logg som omfatter alle nøkler. Derfor lønner det seg å opprette én nøkkel per integrasjon med et beskrivende navn, slik at du kan se nøyaktig hva hver enkelt tjeneste gjør. Øverst på siden står nøkkelens navn, selve nøkkelen og hvor mange oppføringer det er.

Dette viser loggen

• Tidspunkt: hvor lenge siden forespørselen kom inn, f.eks. «3 timer siden». Hold musepekeren over for å få nøyaktig dato og klokkeslett ned til sekundet
• Metode: GET, POST, PUT, DELETE eller PATCH, vist som en farget markering
• Sti: endepunktet som ble truffet, uten domenet, f.eks. product eller order/3658
• Parametre: spørringsstrengen i forespørselen, f.eks. limit=50&offset=0. Feltet er tomt hvis forespørselen ikke hadde parametre, og svært lange strenger vises forkortet
• IP: avsenderens IP-adresse
• Brukeragent: hvilket program som utførte anropet, f.eks. et kommandolinjeverktøy eller integrasjonens eget klientnavn. Hold musepekeren over for å se hele verdien

Sorter, filtrer og søk

Du kan sortere etter Tidspunkt, Metode, Sti og IP ved å klikke på kolonneoverskriften. De nyeste anropene vises øverst som standard. Verdiene i kolonnene Metode, Sti, IP og Brukeragent er klikkbare og fungerer som snarveier:

• Klikk på en metode for å kun se f.eks. alle PUT-anrop. Filteret vises øverst på siden og fjernes igjen ved å klikke på krysset
• Klikk på en sti for å søke etter alle anrop frem til det endepunktet
• Klikk på en IP-adresse for å se alt akkurat denne avsenderen har gjort, eller på en brukeragent for å se alle anrop fra samme program

Søkefeltet søker i sti, parametere, IP og brukeragent samtidig. Antall oppføringer øverst på siden tilpasses etter filteret, slik at du kan bruke det som teller. Du kan vise 25, 50, 100 eller 200 oppføringer per side, og valget lagres til neste gang du åpner loggen.

Dette vises ikke i loggen

Loggfilen er en oversikt over innkommende forespørsler, ikke en fullstendig teknisk sporing. Tre ting lagres bevisst ikke:

• Svarkoden: Du kan ikke se om en forespørsel endte med 200 eller 404. Dette må du lese av i din egen integrasjonslogg
• Innholdet i forespørselen: JSON-dataene du sender med POST og PUT, lagres ikke. Kolonnen «Parametre» viser kun det som står etter spørsmålstegnet i adressen
• Svaret: Dataene som API-et returnerte, lagres heller ikke

Anrop som avvises på grunn av selve nøkkelen, vises heller ikke i loggen. Hvis et anrop avvises med 401 fordi nøkkelen er feil, mangler eller er slettet, blir det aldri knyttet til en nøkkel, og det er derfor ingen linje å logge. Anrop som ender med 403 (nøkkelen har ikke tillatelse til det den prøver på), 404 (ukjent endepunkt), 405 (feil metode) eller 429 (daglig grense nådd), vises derimot i loggen, fordi nøkkelen ble godkjent på forhånd.

API-loggen dekker innkommende anrop til nettbutikken din. Hvis det oppstår feil med webhooks, altså utgående anrop fra nettbutikken din, har disse sin egen logg under Integrasjoner → Webhooks.

Hvor lenge lagres oppføringene

Oppføringer i API-loggen lagres i åtte uker og slettes deretter automatisk. Dette står også nederst på selve loggsiden. Åtte uker er mer enn nok til å feilsøke en integrasjon, men det betyr at loggen ikke kan brukes som dokumentasjon flere år tilbake i tid. Hvis du trenger et lengre spor, må det lagres i den andre enden, altså i systemet som foretar anropet.

Det er en ekstra fordel ved å kjenne til denne grensen: kolonnen «Sist brukt» på API-tilgangssiden beregnes ut fra den nyeste oppføringen i loggen. Hvis en nøkkel ikke har vært brukt på mer enn åtte uker, forsvinner den siste oppføringen, og kolonnen viser en strek i stedet for en dato. En strek betyr altså «ikke brukt i løpet av de siste åtte ukene», ikke nødvendigvis «aldri brukt». Dette er en effektiv måte å finne gamle nøkler på som trygt kan slettes.

Feilsøk en integrasjon som ikke oppfører seg som forventet

Når en integrasjon ikke fungerer som den skal, er det første spørsmålet alltid det samme: kom forespørselen frem i det hele tatt? API-loggen gir svar på dette i løpet av få sekunder, og svaret er uavhengig av hva leverandøren av det andre systemet mener. Gå gjennom trinnene i rekkefølge.

Trinn 1: Kom anropene frem i det hele tatt?

Åpne loggen for nøkkelen som integrasjonen bruker, og se på tidspunktene i tidsrommet der noe skulle ha skjedd.

• Ingen linjer i det hele tatt: da ligger problemet i den andre enden. Enten sender integrasjonen ikke anrop i det hele tatt, eller så blir den avvist på grunn av nøkkelen. Sjekk at den er konfigurert med riktig nøkkel, riktig adresse til nettbutikken din, og at nøkkelen ikke er slettet
• Linjer frem til et bestemt tidspunkt, og deretter ingenting: da sluttet integrasjonen å kjøre der. Noter tidspunktet. Det er nesten alltid akkurat det du trenger for å finne årsaken i det andre systemet
• Linjer hele veien gjennom: anropene kommer frem, og feilen ligger i det som blir anropet. Gå videre til trinn 2

Hvis du har flere nøkler, må du forsikre deg om at du ser på den riktige. Loggen er per nøkkel, og en tom logg betyr bare at akkurat den nøkkelen ikke er brukt.

Trinn 2: Treffer anropene riktig sti og metode?

Sammenlign kolonnene Sti og Metode med det du forventer:

• Hvis du bare ser GET, leser integrasjonen utelukkende. Skulle den også endre noe, mangler det POST-anrop (opprett) eller PUT-anrop (oppdater)
• Hvis du ser en sti som ikke finnes i API-et, er endepunktet feilstavet i konfigurasjonen. Et slikt anrop blir besvart med 404, men det kan du bare se på stien, for loggen viser ikke svarkoder
• Hvis du ser «product» der du forventet «product/123», henter integrasjonen hele listen i stedet for det enkelte produktet. Det er ikke nødvendigvis en feil, men det er ofte forklaringen på høyt forbruk

Sorter etter sti for å samle like forespørsler. Da blir det tydelig hvis ett enkelt endepunkt står for langt de fleste forespørslene.

Trinn 3: Sender integrasjonen de riktige parametrene?

Kolonnen «Parametre» avslører hvordan integrasjonen er konfigurert i praksis. Typiske ting å se etter:

• Er «last_modified» inkludert? Hvis den mangler, henter integrasjonen alt hver gang i stedet for bare det som er endret siden forrige gang
• Står det «limit» og «offset», og teller «offset» opp som forventet? Hvis den fortsetter å være 0, sitter integrasjonen fast på første side og ser aldri resten av dataene dine
• Er det med filtre du ikke hadde regnet med, for eksempel et søk eller en begrensning av felter?

Husk at innholdet i POST- og PUT-anrop ikke lagres. Loggen kan vise deg at det ble sendt en oppdatering til produkt 123, men ikke hvilke verdier den inneholdt.

Trinn 4: Er det riktig avsender?

Kolonnene «IP» og «User agent» viser hvem som bruker nøkkelen. Hvis du ikke kjenner igjen avsenderen, blir nøkkelen brukt av noe annet enn du tror, for eksempel et gammelt testskript, en tidligere leverandør eller en kollega som har kopiert nøkkelen. Klikk på IP-adressen for å se alt akkurat denne avsenderen har gjort.

Det er også her du oppdager om to systemer deler samme nøkkel. Hvis du ser to forskjellige brukeragenter på samme nøkkel, er det to systemer som bruker den, og da kan du verken skille bruksmønstrene deres fra hverandre eller stenge det ene ned uten å påvirke det andre. Opprett en egen nøkkel for hvert system.

Trinn 5: Hvor ofte ringer den?

Sorter etter Tidspunkt og se på avstanden mellom anropene. Kjører synkroniseringen hvert femte minutt når den egentlig skal kjøre en gang i timen? Kommer det en stor klump med forespørsler hver natt? Filtrer etter en metode eller søk på et endepunkt, og bruk antallet øverst på siden som teller.

Hvis det er betydelig flere anrop enn forventet, er dette ofte årsaken til at integrasjonen når den daglige grensen og får 429-feil. Les mer i artikkelen om API-nøkler og daglige grenser.

Til utviklere

Oppføringen skrives i det øyeblikket nøkkelen er godkjent, altså før anropet blir rutet, og før den daglige grensen sjekkes. Det er derfor 403, 404, 405 og 429 vises i loggen, mens 401 aldri gjør det. En tom logg er med andre ord i seg selv et nyttig signal: anropet nådde enten ikke frem, eller så ble det avvist ved autentifiseringen.

Siden verken statuskode, forespørselstekst eller svartekst lagres, er det lurt å logge tidsstempel, metode, sti og spørringsstreng i din egen klient, slik at de to loggene kan sammenlignes. Sett samtidig en fast, gjenkjennelig brukeragent på anropene dine. Det er det eneste feltet i loggen du selv kontrollerer, og det gjør det enkelt å skille ditt eget skript fra tredjepartsintegrasjoner, også når de deler nettbutikk.

Dette bør du ha med deg når du skriver til support

Hvis vi skal se på saken, går det mye raskere hvis du har følgende klart:

• Navnet på nøkkelen som integrasjonen bruker. Send navnet, ikke selve nøkkelen
• Det nøyaktige tidspunktet for et anrop som gikk galt. Hold musepekeren over tidspunktet i loggen for å få dato og klokkeslett ned til sekundet
• Stien og metoden for det aktuelle anropet
• Hva du forventet skulle skje, og hva som skjedde i stedet

Ofte stilte spørsmål

Jeg er ikke teknisk anlagt. Bør jeg i det hele tatt bruke API-loggen?

Ikke i det daglige. Loggen er et feilsøkingsverktøy, ikke noe du trenger å holde øye med. Men den ene tingen du alltid kan bruke den til, er å se om det i det hele tatt kommer inn anrop fra en integrasjon akkurat nå. Hvis for eksempel fraktløsningen din går i stå, kan du åpne loggen for nøkkelen til den og se på den øverste linjen. Hvis det står «2 dager siden», er det den eksterne tjenesten som har stoppet, ikke nettbutikken din. Det svaret er ofte nok til å komme videre.

Hvorfor kan jeg ikke se svarkodene i loggen?

Loggfilen lagrer den innkommende forespørselen, ikke svaret. Hvis du skal feilsøke på feilkoder, må du logge svaret i din egen klient. Loggfilen brukes til å bekrefte at forespørselen kom frem, og til å se hvilken bane og metode den traff, samt hvilke parametere den hadde med seg. Det er verdt å merke seg ett unntak: Anrop som avvises med 401, finnes ikke i loggen i det hele tatt, så en helt tom logg er i seg selv et sterkt tegn på at nøkkelen er feil eller slettet.

Lagersystemet vårt har sluttet å oppdatere. Hva skal jeg gjøre først?

Gå til Integrasjoner → API-tilgang, klikk på Logg ut for lagringssystemets nøkkel, og se på den øverste linjen. Hvis det står «3 dager siden», stoppet systemet for tre dager siden, og feilen ligger hos lagringssystemet. Hvis det står «5 minutter siden», kommer forespørslene frem, og da må du gå videre til kolonnene Sti og Parametre. Noter tidspunktet før du kontakter leverandøren, for det er det første de vil spørre om.

Kan jeg se en samlet logg for alle nøkler i nettbutikken?

Nei, loggen vises per nøkkel. Det er nettopp derfor det er en god vane å opprette én nøkkel per integrasjon med et beskrivende navn, for eksempel «Lagersystem» eller «Prisvogter». På siden for API-tilgang kan du sortere etter «Sist brukt» og raskt se hvilke nøkler som faktisk er aktive, og kolonnen «Daglig grense» viser forbruk og grense per nøkkel. Hvis du skal sammenligne forbruk på tvers, er oversikten det rette stedet, ikke loggen.

Vårt økonomisystem har bokført en ordre feil. Kan jeg se i loggen hva som ble sendt?

Du kan se at det ble sendt en forespørsel, når, med hvilken metode og til hvilken sti, f.eks. en PUT til order/3658. Selve innholdet lagres ikke, så du kan ikke se hvilke beløp eller kontoer som fulgte med. For det må du bruke vedlegget eller loggen i regnskapssystemet. Loggen kan derimot fastslå tidspunktet helt nøyaktig, og det er som regel nok til å finne den riktige posteringen i den andre enden.

Loggfilen viser forespørsler hvert femte minutt hele natten. Er det et problem?

Ikke i seg selv, men det er verdt å regne på. Én oppdatering hvert femte minutt blir til knapt 300 oppdateringer i løpet av et døgn, og hvis integrasjonen henter flere sider om gangen, blir tallet enda større. Dette teller med i nøkkelens daglige grense. Se på kolonnen «Parametre»: hvis det ikke er noen «load_modified» med, henter integrasjonen hele katalogen hver gang, og da er de aller fleste forespørslene bortkastet. Be leverandøren om å endre det slik at den kun henter endringer siden forrige gang.

Kan jeg bruke API-loggen som dokumentasjon overfor revisoren min?

Nei. Oppføringene slettes automatisk etter åtte uker, og loggen inneholder verken beløp eller innholdet i forespørslene. Den dokumenterer at et system har hentet data fra nettbutikken din på et gitt tidspunkt, ikke hva som ble utvekslet. For regnskapsdokumentasjon må du bruke ordrene i nettbutikken og bilagene i regnskapssystemet.

Vår prisovervåker sier at de oppdaterer prisene hver time, men prisene endrer seg ikke. Hvordan sjekker jeg dette?

Åpne loggen for prisovervåkerens nøkkel og klikk på PUT i kolonnen Metode for å filtrere etter metoden. Hvis det ikke finnes noen PUT-anrop i det hele tatt, leser tjenesten bare og skriver ikke, uansett hva som står i konfigurasjonen deres. Hvis det er PUT-anrop til produktstier hver time, kommer oppdateringene frem. Sjekk da først om nøkkelen er satt til «Kun lesing», for da blir skrivningene avvist med 403 selv om anropene står i loggen. Hvis nøkkelen er riktig angitt, må du undersøke om det er de riktige produktene som berøres, eller om prisene blir overskrevet av noe annet i etterkant.

Trenger du hjelp med API-integrasjon? Kontakt oss på support@shoporama.dk.