REST API

Oversigt

Shoporamas REST API giver dig mulighed for at integrere din webshop med eksterne systemer, fx ERP, lagerstyring, PIM, CRM og andre tjenester. API'et understøtter CRUD (opret, læs, opdater, slet) på de fleste ressourcer i din webshop.

Dokumentation

Den fulde API-dokumentation med alle endpoints, parametre og eksempler finder du i vores interaktive Swagger-dokumentation:

Åbn Swagger-dokumentationen

Her kan du afprøve API-kald direkte i browseren og se alle tilgængelige felter og parametre for hver ressource.

Kom i gang

1. Gå til Integrationer → API-adgang i din Shoporama-administration
2. Opret en ny API-nøgle, mens du er logget ind som bruger med rollen Fuld adgang, så nøglen ikke begrænses af en rolle (se afsnittet Nøgler og brugerroller nedenfor). Har du selv rollen Udvikler, og skal nøglen kunne mere end rollen, så bed en bruger med Fuld adgang om at oprette den
3. Vælg rettigheder for nøglen: Alle, Kun læse, eller Kun skrive. Rettigheden gælder hele nøglen, ikke den enkelte ressource
4. Brug nøglen i Authorization-headeren på dine API-kald

Autentificering

Tilføj din API-nøgle i Authorization-headeren. Du kan enten sende nøglen direkte eller bruge Bearer-format:

Authorization: DIN-API-NØGLE

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

Nøgler og brugerroller

Siden API-adgang kan åbnes af brugere med rollen Fuld adgang eller Udvikler. Med rollen Udvikler ser du kun de nøgler, du selv har oprettet med den rolle eller godkendt via OAuth, og kun deres log. Hvem der står bag en nøgle, afgør, hvor meget den kan:

• Oprettet af en bruger med Fuld adgang: nøglen hører til shoppen og kan alt, adgangsniveauet tillader. Den virker stadig, hvis brugeren senere fjernes eller får en anden rolle. Det samme gælder alle nøgler, der blev oprettet under API-adgang, før rollerne blev indført
• Oprettet af en bruger med rollen Udvikler: nøglen er knyttet til brugeren og kan højst det samme som rollen. Udvikler har fx ikke adgang til ordrer, kunder, lager, og statistik, så en integration, der skal hente ordrer, skal have en nøgle fra en bruger med Fuld adgang. Fjernes brugeren fra webshoppen, tilbagekaldes nøglen
• Fra OAuth: nøglen er knyttet til den bruger, der godkendte forbindelsen. Har brugeren fået en anden rolle end Fuld adgang, fx Medarbejder eller Marketing, kan nøglen kun det, rollen må

For en nøgle, der følger en rolle, gælder:

• GET kræver, at rollen kan se området, og POST, PUT, og DELETE, at den kan rette det
• /stats og /top-products kræver desuden tilvalget Omsætning og statistik
• DELETE af produkter, ordrer, og kunder kræver tilvalget Sletning og masseimport. Det samme gælder POST med en liste af produkter eller kunder (masseimport)
• Kreditering, annullering, og ændring af betalt-status på ordrer kræver tilvalget Refundering og annullering
• Uden tilvalget Kostpriser og avance fjernes kostpriser og avance fra svarene, og disse kald afvises helt: skrivning af kostpriser, /stock/{id}/settings (også GET), /stock-value-apply, og rapporterne sales/margin, products/abc, og inventory/turnover under /stats
• Har brugeren fået rollen Leverandør, kan nøglen kun arbejde med leverandørens egne produkter, ét ad gangen på id. Den kan hente og ændre dem, og med tilvalget Sletning og masseimport også slette dem. Den kan desuden hente og uploade billeder i billedarkivet. Produktlister og oprettelse af nye produkter sker i admin. Vælg altid en leverandør til brugeren under Leverandøropsætning i Firma → Brugere, ellers er nøglen ikke afgrænset til leverandørens egne produkter

Rollen tjekkes ved hvert kald, så ændrer firmaadministratoren den, gælder den nye rolle fra næste kald. Læs mere i Roller og rettigheder.

Tilgængelige ressourcer

API'et giver adgang til følgende ressourcer. Alle endpoints tilgås under https://dinshop.dk/REST/:

Produkter og katalog

• /product: Produkter (med varianter, billeder, priser, kategorier, ekstrafelter)
• /category: Kategorier
• /brand: Brands/varemærker
• /manufacturer: Fabrikanter
• /supplier: Leverandører
• /product-label: Produktlabels
• /profile, /profile-attribute, /profile-attribute-value: Produktprofiler, attributter og værdier
• /product/{id}/restore: Gendan et slettet produkt
• /product-review: Produktanmeldelser. Vis, godkend, skjul, og slet anmeldelser
• /waitlist: Produkter med kunder på venteliste og antallet der venter (uden e-mailadresser). Ventelisten for et produkt kan ryddes
• /wishlist-product: Produkter på flest ønskelister (uden kundedata)

Lager

• /stock: Lagerbeholdning og posteringer
• /batch: Lagerbatches
• /stock/{id}/settings: Minimumslager og kostpris for et produkt
• /stock-location: Lagerlokationer
• /stock-move: Flyt lager mellem lokationer
• /stock-movement: Lagerbevægelser
• /stock-value-apply: Udfyld manglende kostpriser på lagerposteringer og genberegn lagerværdien

Ordrer og kunder

• /order: Ordrer
• /order/{id}/create-label: Opret fragtlabel på ordre
• /order/{id}/download-label: Download fragtlabel
• /order-queue: Ordrekø
• /order-label: Ordrelabels
• /order-return: Returneringer
• /order-return/{id}/received: Markér en godkendt retur som modtaget
• /order-status: Skift status på op til 25 ordrer i ét kald. Med dry_run ændres intet, og svaret viser, hvad ændringen vil udløse (fx mails og betaling)
• /order/{id}/pick: Registrér plukkede antal på en ordre
• /order-pick-list: Plukkelisten med ordrer der venter på at blive pakket
• /customer: Kunder
• /client: Gæstekunder, der har handlet uden konto
• /customer-field: Kundefelter
• /voucher: Rabatkoder og gavekort

Indhold

• /page: Statiske sider
• /blog-post: Blogindlæg
• /landing-page og /landing-page-item: Landingssider og elementer. GET /landing-page/{id} returnerer nu sidens regler (rules) og match-type (match_type) direkte i svaret, så du slipper for et separat kald til /landing-page-item
• /menu: Menuer og navigation

Nyhedsbrev

• /newsletter-list: Nyhedsbrevslister
• /newsletter-subscriber: Abonnenter
• /newsletter-campaign: Kampagner

Opsætning

• /shipping: Fragtmetoder. Med PUT kan du også sætte fri fragt, vægtgrænse, moms, og kundemails for metoden
• /shipping-price: Fragtpriser pr. land og fragtmetode
• /shipping-weight-price: Ret priserne på eksisterende vægtintervaller
• /payment_gateway: Betalingsmetoder
• /country: Lande
• /redirect: URL-redirects
• /webhook: Webhooks
• /webshop-settings: Webshoppens indstillinger fordelt på sektionerne generelt, produktvisning og søgning, kurv og checkout, lager, ordremails, og søgemaskiner. Blandt andet valuta, domæne, moms-visning, og adgangsoplysninger kan ikke ændres her

Statistik

• /stats/{group}/{view}: Statistikrapporterne fra admin inden for salg, produkter, lager, marketing, og kunder. Tallene beregnes på samme måde som i admin, så de stemmer for samme periode

Tema

• /theme-settings: Temaindstillinger for det aktive tema. Kun indstillinger, der er erklæret i temaets theme_settings.json, kan sættes
• /theme-stylesheet: Ret dele af shoppens eget stylesheet (søg og erstat, eller tilføj til sidst) i stedet for at overskrive det hele
• /theme-file: Læs, opret, opdater og slet filer i dine temaer. Kræver at "Adgang til tema-filer" er aktiveret på API-nøglen

HTTP-metoder

• GET: Hent en liste eller en enkelt ressource
• POST: Opret en ny ressource
• PUT: Opdater en eksisterende ressource
• DELETE: Slet en ressource

Eksempler

Hent produkter:

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

Opret et produkt:

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

Opdater 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 stien er produktets id, og count er den nye samlede beholdning.

Filtrering og paging

Liste-endpoints understøtter følgende query-parametre:

• ?limit=25: antal resultater pr. side. Den øvre grænse afhænger af endpointet (fx 250 på /product), og den fremgår af Swagger-dokumentationen
• ?offset=0: spring resultater over (til paging)
• ?search=tekst: fritekst-søgning
• ?fields=name,price: begræns returnerede felter
• ?last_modified=2026-01-01: kun ressourcer ændret siden dato

Webhooks

Du kan oprette webhooks via API'et, så dit system automatisk får besked når der sker ændringer. Ved oprettelse modtager du en secret som bruges til at verificere webhook-kald via HMAC.

Validering: det afviser API'et

For at beskytte shoppens data tjekker API'et en række felter, før noget gemmes. Afvises en værdi, svares der med 400 og en forklaring, og der gemmes intet fra kaldet:

• PUT /theme-settings valideres mod det aktive temas theme_settings.json. Ukendte indstillinger og ugyldige værdier for til/fra, farver, og lister afvises. Billeder skal komme fra shoppens billedarkiv, og farlig HTML som scripts fjernes fra tekstfelter. Har temaet ingen theme_settings.json, kan indstillinger ikke sættes via API'et
• PUT /country: momssatser skal ligge mellem 0 og 99,99, fri fragt skal være 0 eller mere, og standard-fragtmetoden skal være aktiv i landet
• add_label_id på ordrer skal være en ordrelabel i shoppen
• order_notice_to på PUT /webshop må kun indeholde e-mailadresser på shoppens brugere eller adresser, der allerede står i feltet

Når API'et henter en fil fra en URL, fx logo, favicon, PDF, produktfiler, eller billeder til billedarkivet, skal adressen være en offentlig http- eller https-adresse. Der følges højst 5 omdirigeringer, og en PDF må højst fylde 32 MB. Et image_id til logo eller favicon skal tilhøre shoppen. Opfylder en fil ikke kravene, bliver den ikke gemt, så tjek bagefter, at filen er kommet med.

Felter, grænser, og fejlsvar for hvert endpoint finder du i REST API-dokumentationen og i Swagger.

Svarkoder

• 200: Succes
• 201: Ressource oprettet
• 204: Opdatering/sletning lykkedes
• 400: Ugyldig forespørgsel
• 401: Ikke autoriseret (forkert, manglende, eller tilbagekaldt API-nøgle). En nøgle fra OAuth tilbagekaldes fx, når brugeren, der godkendte den, fjernes fra shoppen. Det samme gælder en nøgle, som en bruger med rollen Udvikler har oprettet
• 403: Nøglen er gyldig, men har ikke rettigheder til handlingen, fx en nøgle med Kun læse der forsøger at skrive (fejlkoden insufficient_scope), eller en nøgle, hvor rollen hos brugeren bag nøglen ikke tillader kaldet (fejlkoden insufficient_role)
• 404: Ressource ikke fundet
• 409: Konflikt med data i shoppen, fx PUT /customer med en e-mail, som en anden kunde allerede bruger, eller PUT /theme-stylesheet, hvor stylesheetet er ændret, siden du hentede det. Intet gemmes
• 429: For mange kald (rate limit)

API-loggen: se hvad der faktisk kaldes

Hver API-nøgle har sin egen log over de kald der er kommet ind. Det er det værktøj du skal bruge når en integration opfører sig anderledes end forventet, for loggen viser hvad der reelt ramte din shop, ikke hvad den eksterne leverandør tror der bliver sendt.

Sådan finder du loggen

1. Gå til Integrationer → API-adgang
2. Find den nøgle i listen som integrationen bruger
3. Klik på knappen Log ud for nøglen

Har du rollen Udvikler, ser du kun dine egne nøgler og deres log. Bed en bruger med Fuld adgang om at åbne loggen for de øvrige nøgler.

Loggen hører altid til én bestemt nøgle, og der findes ikke en samlet log på tværs af alle nøgler. Derfor betaler det sig at oprette én nøgle pr. integration med et sigende navn, så du kan se præcis hvad hver enkelt tjeneste laver. Øverst på siden står nøglens navn, selve nøglen, og hvor mange posteringer der er.

Det viser loggen

• Tidspunkt: hvor lang tid siden kaldet kom ind, fx "3 timer siden". Hold musen over for at få præcis dato og klokkeslæt ned til sekundet
• Metode: GET, POST, PUT, DELETE, eller PATCH, vist som et farvet mærke
• Sti: det endpoint der blev ramt, uden domænet, fx product eller order/3658
• Parametre: query-strengen på kaldet, fx limit=50&offset=0. Feltet er tomt hvis kaldet ikke havde parametre, og meget lange strenge vises forkortet
• IP: afsenderens IP-adresse
• User agent: hvilket program der kaldte, fx et kommandolinjeværktøj eller integrationens eget klientnavn. Hold musen over for at se hele værdien

Sortér, filtrér, og søg

Du kan sortere på Tidspunkt, Metode, Sti, og IP ved at klikke på kolonneoverskriften. Nyeste kald står øverst som standard. Værdierne i kolonnerne Metode, Sti, IP, og User agent er samtidig klikbare og virker som genveje:

• Klik på en metode for kun at se fx alle PUT-kald. Filteret vises øverst på siden og fjernes igen med krydset
• Klik på en sti for at søge alle kald frem til det endpoint
• Klik på en IP-adresse for at se alt hvad netop den afsender har lavet, eller på en user agent for at se alle kald fra samme program

Søgefeltet søger i sti, parametre, IP, og user agent på én gang. Antallet af posteringer øverst på siden følger filtret, så du kan bruge det som tæller. Du kan vise 25, 50, 100, eller 200 posteringer pr. side, og valget huskes til næste gang du åbner loggen.

Det viser loggen ikke

Loggen er en oversigt over indgående kald, ikke en fuld teknisk sporing. Tre ting gemmes bevidst ikke:

• Svarkoden: du kan ikke se om et kald endte i 200 eller 404. Det skal læses i din egen integrations log
• Indholdet af kaldet: den JSON du sender med POST og PUT gemmes ikke. Kolonnen Parametre viser kun det der står efter spørgsmålstegnet i adressen
• Svaret: de data API'et returnerede gemmes heller ikke

Kald der bliver afvist på selve nøglen, står heller ikke i loggen. Bliver et kald afvist med 401 fordi nøglen er forkert, mangler, eller er slettet, når det aldrig at blive knyttet til en nøgle, og der er derfor ingen linje at logge. Kald der ender i 403 (nøglen, eller rollen hos brugeren bag den, må ikke det den forsøger), 404 (ukendt endpoint), 405 (forkert metode), eller 429 (daglig grænse ramt), står derimod i loggen, fordi nøglen blev godkendt inden.

API-loggen dækker kald ind til din shop. Går det galt med webhooks, altså kald ud fra din shop, har de deres egen log under Integrationer → Webhooks.

Hvor længe gemmes posteringerne

Posteringer i API-loggen gemmes i otte uger og slettes derefter automatisk. Det står også nederst på selve log-siden. Otte uger er rigeligt til at fejlsøge en integration, men det betyder at loggen ikke kan bruges som dokumentation år tilbage. Har du brug for et længere spor, skal det gemmes i den anden ende, altså i det system der kalder.

Der er en sidegevinst ved at kende den grænse: kolonnen Sidst brugt på API-adgang-siden regnes ud fra den nyeste postering i loggen. Har en nøgle ikke været brugt i mere end otte uger, forsvinder dens sidste postering, og kolonnen viser en streg i stedet for en dato. En streg betyder altså "ikke brugt inden for de sidste otte uger", ikke nødvendigvis "aldrig brugt". Det er en effektiv måde at finde gamle nøgler på som trygt kan slettes.

Fejlsøg en integration der ikke opfører sig som forventet

Når en integration ikke gør det den skal, er det første spørgsmål altid det samme: kom kaldet overhovedet frem? API-loggen svarer på det på få sekunder, og den svarer uafhængigt af hvad leverandøren af det andet system mener. Gå trinene igennem i rækkefølge.

Trin 1: Kom kaldene overhovedet frem?

Åbn loggen for den nøgle integrationen bruger, og kig på tidspunkterne i det tidsrum hvor noget skulle være sket.

• Ingen linjer overhovedet: så ligger problemet i den anden ende. Enten kalder integrationen slet ikke, eller også bliver den afvist på nøglen. Tjek at den er sat op med den rigtige nøgle, den rigtige adresse på din shop, og at nøglen ikke er slettet
• Linjer indtil et bestemt tidspunkt, og så ingenting: så holdt integrationen op med at køre der. Notér tidspunktet. Det er næsten altid præcis dét man skal bruge for at finde årsagen i det andet system
• Linjer hele vejen igennem: kaldene kommer frem, og fejlen ligger i hvad der bliver kaldt. Gå videre til trin 2

Har du flere nøgler, så sikr dig at du kigger på den rigtige. Loggen er pr. nøgle, og en tom log betyder kun at netop den nøgle ikke er brugt.

Trin 2: Rammer kaldene den rigtige sti og metode?

Sammenlign kolonnerne Sti og Metode med det du forventer:

• Ser du kun GET, læser integrationen udelukkende. Skulle den også ændre noget, mangler der POST-kald (opret) eller PUT-kald (opdater)
• Ser du en sti der ikke findes i API'et, er endpointet stavet forkert i opsætningen. Sådan et kald bliver besvaret med 404, men det kan du kun se på stien, for loggen viser ikke svarkoder
• Ser du product hvor du forventede product/123, henter integrationen hele listen i stedet for det enkelte produkt. Det er ikke nødvendigvis en fejl, men det er ofte forklaringen på et højt forbrug

Sortér på Sti for at samle ens kald. Så springer det i øjnene hvis ét enkelt endpoint står for langt de fleste kald.

Trin 3: Sender integrationen de rigtige parametre?

Kolonnen Parametre afslører hvordan integrationen i praksis er sat op. Typiske ting at kigge efter:

• Er der en last_modified med? Mangler den, henter integrationen alt hver gang i stedet for kun det der er ændret siden sidst
• Står der limit og offset, og tæller offset op som forventet? Bliver den ved med at være 0, sidder integrationen fast på første side og ser aldrig resten af dine data
• Er der filtre med som du ikke havde regnet med, fx en søgning eller en begrænsning af felter?

Husk at indholdet af POST- og PUT-kald ikke gemmes. Loggen kan vise dig at der blev sendt en opdatering til produkt 123, men ikke hvilke værdier der stod i den.

Trin 4: Er det den rigtige afsender?

Kolonnerne IP og User agent viser hvem der bruger nøglen. Genkender du ikke afsenderen, bliver nøglen brugt af noget andet end du tror, fx et gammelt testscript, en tidligere leverandør, eller en kollega der har kopieret nøglen. Klik på IP-adressen for at se alt hvad netop den afsender har lavet.

Det er også her du opdager om to systemer deler samme nøgle. Ser du to forskellige user agents på den samme nøgle, er der to systemer om den, og så kan du hverken skille deres forbrug ad eller lukke det ene ned uden at ramme det andet. Opret en nøgle til hvert system.

Trin 5: Hvor tit kalder den?

Sortér på Tidspunkt og kig på afstanden mellem kaldene. Kører synkroniseringen hvert femte minut hvor den burde køre en gang i timen? Kommer der en stor klump kald hver nat? Filtrér på en metode eller søg på et endpoint, og brug antallet øverst på siden som tæller.

Er der markant flere kald end forventet, er det ofte forklaringen på at integrationen rammer den daglige grænse og får 429-fejl. Læs mere i artiklen om API-nøgler og daglige grænser.

Til udviklere

Posteringen skrives i det øjeblik nøglen er godkendt, altså inden kaldet bliver rutet, og inden den daglige grænse tjekkes. Det er derfor 403, 404, 405, og 429 optræder i loggen, mens 401 aldrig gør. En tom log er med andre ord i sig selv et brugbart signal: kaldet nåede enten ikke frem, eller også blev det afvist på autentificeringen.

Da hverken statuskode, request-body, eller response-body gemmes, er det en god idé at logge tidsstempel, metode, sti, og query-streng i din egen klient, så de to logs kan holdes op mod hinanden. Sæt samtidig en fast, genkendelig user agent på dine kald. Det er det eneste felt i loggen du selv styrer, og det gør det nemt at skille dit eget script fra tredjeparts-integrationer, også når de deler shop.

Det skal du have med når du skriver til support

Skal vi kigge med, går det meget hurtigere hvis du har følgende klar:

• Navnet på den nøgle integrationen bruger. Send navnet, ikke selve nøglen
• Præcist tidspunkt for et kald der gik galt. Hold musen over tidspunktet i loggen for at få dato og klokkeslæt ned til sekundet
• Sti og metode på det kald
• Hvad du forventede skulle ske, og hvad der skete i stedet

Ofte stillede spørgsmål

Jeg er ikke teknisk. Skal jeg overhovedet bruge API-loggen?

Ikke i det daglige. Loggen er et fejlsøgningsværktøj, ikke noget du behøver holde øje med. Men den ene ting du altid kan bruge den til, er at se om der overhovedet kommer kald ind fra en integration lige nu. Går fx din fragtløsning i stå, så åbn loggen for dens nøgle og kig på den øverste linje. Står der "2 dage siden", er det den eksterne tjeneste der er stoppet, ikke din shop. Det svar er tit nok til at komme videre.

Hvorfor kan jeg ikke se svarkoderne i loggen?

Loggen gemmer det indgående kald, ikke svaret. Skal du fejlsøge på fejlkoder, skal du logge svaret i din egen klient. Loggen bruges til at bekræfte at kaldet nåede frem, og til at se hvilken sti og metode det ramte, og hvilke parametre det havde med. Én undtagelse er værd at kende: kald der afvises med 401, findes slet ikke i loggen, så en helt tom log er i sig selv et stærkt fingerpeg om at nøglen er forkert eller slettet.

Vores lagersystem er holdt op med at opdatere. Hvad gør jeg først?

Gå til Integrationer → API-adgang, klik Log ud for lagersystemets nøgle, og kig på den øverste linje. Står der "3 dage siden", stoppede systemet for tre dage siden, og fejlen ligger hos lagersystemet. Står der "5 minutter siden", kommer kaldene frem, og så skal du videre til kolonnerne Sti og Parametre. Notér tidspunktet inden du kontakter leverandøren, for det er det første de spørger om.

Kan jeg se en samlet log for alle nøgler på shoppen?

Nej, loggen vises pr. nøgle. Det er netop derfor det er en god vane at oprette én nøgle pr. integration med et sigende navn, fx "Lagersystem" eller "Prisvogter". På API-adgang-siden kan du sortere på Sidst brugt og hurtigt se hvilke nøgler der reelt er aktive, og kolonnen Daglig grænse viser forbrug og grænse pr. nøgle. Skal du sammenligne forbrug på tværs, er oversigten det rigtige sted, ikke loggen.

Vores økonomisystem har bogført en ordre forkert. Kan jeg se i loggen hvad der blev sendt?

Du kan se at der blev sendt et kald, hvornår, med hvilken metode, og til hvilken sti, fx en PUT til order/3658. Selve indholdet gemmes ikke, så du kan ikke se hvilke beløb eller konti der fulgte med. Til det skal du bruge bilaget eller loggen i økonomisystemet. Loggen kan til gengæld fastslå tidspunktet helt præcist, og det er som regel nok til at finde den rigtige postering i den anden ende.

Loggen viser kald hvert femte minut hele natten. Er det et problem?

Ikke i sig selv, men det er værd at regne på. Ét kald hvert femte minut bliver til knap 300 kald i døgnet, og henter integrationen flere sider ad gangen, ganges tallet op. Det tæller med i nøglens daglige grænse. Kig på kolonnen Parametre: er der ingen last_modified med, henter integrationen hele kataloget hver gang, og så er langt de fleste kald spildt. Bed leverandøren skifte til kun at hente ændringer siden sidst.

Kan jeg bruge API-loggen som dokumentation over for min revisor?

Nej. Posteringerne slettes automatisk efter otte uger, og loggen indeholder hverken beløb eller indholdet af kaldene. Den dokumenterer at et system har kaldt din shop på et givent tidspunkt, ikke hvad der blev udvekslet. Til regnskabsdokumentation skal du bruge ordrerne i shoppen og bilagene i økonomisystemet.

Vores prisvogter siger de opdaterer priser hver time, men priserne ændrer sig ikke. Hvordan tjekker jeg det?

Åbn loggen for prisvogterens nøgle og klik på PUT i kolonnen Metode for at filtrere på metoden. Er der ingen PUT-kald overhovedet, læser tjenesten kun og skriver ikke, uanset hvad der står i deres opsætning. Er der PUT-kald til product-stier hver time, kommer opdateringerne frem. Tjek så først om nøglen er sat til Kun læse, eller om den hører til en bruger, hvis rolle kun kan se produkter, fx Udvikler eller Marketing. I begge tilfælde bliver skrivningerne afvist med 403, selvom kaldene står i loggen. Er nøglen sat rigtigt, skal du undersøge om det er de rigtige produkter der rammes, eller om priserne bliver overskrevet af noget andet bagefter.

Vores integration får 403, selvom nøglen har adgangsniveauet Alle. Hvorfor?

Har svaret fejlkoden insufficient_role, hører nøglen til en bruger med en anden rolle end Fuld adgang, typisk fordi den er oprettet af en bruger med rollen Udvikler. Sådan en nøgle kan højst det samme som rollen, og svaret nævner rollens navn. Listen under API-adgang viser ikke, hvem der har oprettet en nøgle. Er du firmaadministrator, kan du se det under Firma → Brugere → Aktivitetslog. Løsningen er at oprette en ny nøgle, mens du er logget ind som en bruger med Fuld adgang, sætte den ind i integrationen, og slette den gamle. Bruger integrationen OAuth, skal forbindelsen i stedet godkendes igen af en bruger med Fuld adgang. Læs mere i Roller og rettigheder.

Har du brug for hjælp med API-integration? Kontakt os på support@shoporama.dk.