REST API

Översikt

Shoporamas REST-API ger dig möjlighet att integrera din webbutik med externa system – ERP, lagerhantering, PIM, CRM och andra tjänster. API:et stöder CRUD (skapa, läsa, uppdatera, radera) för de flesta resurserna i din webbutik.

Dokumentation

Den fullständiga API-dokumentationen med alla endpoints, parametrar och exempel hittar du i vår interaktiva Swagger-dokumentation:

Öppna Swagger-dokumentationen

Här kan du testa API-anrop direkt i webbläsaren och se alla tillgängliga fält och parametrar för varje resurs.

Kom igång

1. Gå till Integrationer → API-åtkomst i din Shoporama-administration
2. Skapa en ny API-nyckel
3. Välj behörigheter för nyckeln: Alla, Endast läsning eller Endast skrivning. Behörigheten gäller hela nyckeln, inte den enskilda resursen
4. Använd nyckeln i Authorization-rubriken i dina API-anrop

Autentisering

Lägg till din API-nyckel i Authorization-rubriken. Du kan antingen skicka nyckeln direkt eller använda Bearer-formatet:

Authorization: DIN-API-NYCKEL

# Eller med Bearer:
Authorization: Bearer DIN-API-NYCKEL

Tillgängliga resurser

API:et ger åtkomst till följande resurser. Alla endpoints nås via https://dinshop.dk/REST/:

Produkter och katalog

• /product — Produkter (med varianter, bilder, priser, kategorier, extrafält)
• /category — Kategorier
• /brand — Varumärken
• /manufacturer — Tillverkare
• /supplier — Leverantörer
• /product-label — Produktetiketter
• /profile, /profile-attribute, /profile-attribute-value — Produktprofiler, attribut och värden

Lager

• /stock — Lagerbeholdning och poster
• /batch — Lagerpartier

Order och kunder

• /order — Order
• /order/{id}/create-label — Skapa fraktetikett för order
• /order/{id}/download-label — Ladda ner fraktetikett
• /order-queue — Orderkö
• /order-label — Orderetiketter
• /order-return — Returer
• /customer — Kunder
• /customer-field — Kundfält
• /voucher — Rabattkoder och presentkort

Innehåll

• /page — Statiska sidor
• /blog-post — Blogginlägg
• /landing-page och /landing-page-item — Landningssidor och element. GET /landing-page/{id} returnerar nu sidans regler (rules) och matchtyp (match_type) direkt i svaret, så att du slipper ett separat anrop till /landing-page-item
• /menu — Menyer och navigering

Nyhetsbrev

• /newsletter-list — Nyhetsbrevslistor
• /newsletter-subscriber — Prenumeranter
• /newsletter-campaign — Kampanjer

Inställningar

• /shipping — Fraktmetoder
• /payment_gateway — Betalningsmetoder
• /country — Länder
• /redirect — URL-omdirigeringar
• /webhook — Webhooks

Temafiler

• /theme-file — Läs, skapa, uppdatera och ta bort filer i dina teman. Kräver att "Åtkomst till temafiler" är aktiverat på API-nyckeln

HTTP-metoder

• GET — Hämta en lista eller en enskild resurs
• POST — Skapa en ny resurs
• PUT — Uppdatera en befintlig resurs
• DELETE — Ta bort en resurs

Exempel

Hämta produkter:

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

Skapa en produkt:

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

Uppdatera lagerbeholdning:

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

Siffran i sökvägen är produktens ID och count är det nya totala lagret.

Filtrering och sidindelning

List-endpoints stöder följande sökparametrar:

• ?limit=25 — antal resultat per sida. Den övre gränsen beror på slutpunkten (t.ex. 250 på /product) och framgår av Swagger-dokumentationen
• ?offset=0 — hoppa över resultat (för sidindelning)
• ?search=text — fritextsökning
• ?fields=name,price — begränsa antalet fält som returneras
• ?last_modified=2026-01-01 — endast resurser som har ändrats efter detta datum

Webhooks

Du kan skapa webhooks via API:et så att ditt system automatiskt får ett meddelande när ändringar sker. Vid skapandet får du en hemlig nyckel som används för att verifiera webhook-anrop via HMAC.

Svarskoder

• 200 — Framgång
• 201 — Resurs skapad
• 204 — Uppdatering/radering lyckades
• 400 — Ogiltig förfrågan
• 401 — Ej auktoriserad (felaktig eller saknad API-nyckel)
• 403 — Nyckeln är giltig, men har inte behörighet för åtgärden (t.ex. en nyckel med endast läsbehörighet som försöker skriva)
• 404 — Resursen hittades inte
• 429 — För många anrop (begränsning av anropsfrekvens)

API-loggen: se vad som faktiskt anropas

Varje API-nyckel har sin egen logg över de anrop som har kommit in. Det är det verktyg du ska använda när en integration beter sig annorlunda än förväntat, eftersom loggen visar vad som faktiskt nådde din butik, inte vad den externa leverantören tror att det skickas.

Så här hittar du loggen

1. Gå till Integrationer → API-åtkomst
2. Hitta den nyckel i listan som integrationen använder
3. Klicka på knappen Logga ut för nyckeln

Loggen hör alltid till en specifik nyckel, och det finns ingen samlad logg som omfattar alla nycklar. Därför lönar det sig att skapa en nyckel per integration med ett beskrivande namn, så att du kan se exakt vad varje enskild tjänst gör. Högst upp på sidan står nyckelns namn, själva nyckeln och hur många poster det finns.

Loggen visar

• Tidpunkt: hur länge sedan anropet kom in, t.ex. ”för 3 timmar sedan”. Håll muspekaren över för att se exakt datum och klockslag ned till sekunden
• Metod: GET, POST, PUT, DELETE eller PATCH, visad som en färgad markering
• Sökväg: den endpoint som träffades, utan domänen, t.ex. product eller order/3658
• Parametrar: frågesträngen för anropet, t.ex. limit=50&offset=0. Fältet är tomt om anropet inte hade några parametrar, och mycket långa strängar visas förkortade
• IP: avsändarens IP-adress
• Användaragent: vilket program som gjorde anropet, t.ex. ett kommandoradsverktyg eller integrationens eget klientnamn. Håll muspekaren över för att se hela värdet

Sortera, filtrera och sök

Du kan sortera efter Tidpunkt, Metod, Sökväg och IP genom att klicka på kolumnrubriken. De senaste anropen visas som standard överst. Värdena i kolumnerna Metod, Sökväg, IP och Användaragent är samtidigt klickbara och fungerar som genvägar:

• Klicka på en metod för att endast visa t.ex. alla PUT-anrop. Filtret visas högst upp på sidan och tas bort igen med krysset
• Klicka på en sökväg för att söka fram alla anrop till den slutpunkten
• Klicka på en IP-adress för att se allt som just den avsändaren har gjort, eller på en användaragent för att se alla anrop från samma program

Sökfältet söker i sökväg, parametrar, IP och användaragent samtidigt. Antalet poster högst upp på sidan anpassas efter filtret, så du kan använda det som räknare. Du kan visa 25, 50, 100 eller 200 poster per sida, och valet sparas till nästa gång du öppnar loggen.

Det visar inte loggen

Loggen är en översikt över inkommande anrop, inte en fullständig teknisk spårning. Tre saker sparas medvetet inte:

• Svarskoden: du kan inte se om ett anrop slutade med 200 eller 404. Det måste läsas av i din egen integrationslogg
• Innehållet i anropet: den JSON som du skickar med POST och PUT sparas inte. Kolumnen Parametrar visar endast det som står efter frågetecknet i adressen
• Svaret: de data som API:et returnerade sparas inte heller

Anrop som avvisas på grund av själva nyckeln finns inte heller i loggen. Om ett anrop avvisas med 401 eftersom nyckeln är felaktig, saknas eller har raderats, hinner det aldrig kopplas till en nyckel, och det finns därför ingen rad att logga. Anrop som resulterar i 403 (nyckeln har inte behörighet att utföra det den försöker), 404 (okänd slutpunkt), 405 (felaktig metod) eller 429 (daglig gräns uppnådd) finns däremot med i loggen, eftersom nyckeln godkändes tidigare.

API-loggen täcker anrop till din butik. Om det uppstår problem med webhooks, det vill säga anrop från din butik, finns de i en egen logg under Integrationer → Webhooks.

Hur länge sparas posterna

Poster i API-loggen sparas i åtta veckor och raderas därefter automatiskt. Det står också längst ner på själva loggsidan. Åtta veckor är mer än tillräckligt för att felsöka en integration, men det innebär att loggen inte kan användas som dokumentation flera år tillbaka. Om du behöver en längre historik måste den sparas i den andra änden, det vill säga i det system som anropar.

Det finns en extra fördel med att känna till denna gräns: kolumnen ”Senast använd” på API-åtkomstsidan beräknas utifrån den senaste posten i loggen. Om en nyckel inte har använts på mer än åtta veckor försvinner den senaste posten, och kolumnen visar en streck istället för ett datum. En streck betyder alltså ”inte använd under de senaste åtta veckorna”, inte nödvändigtvis ”aldrig använd”. Det är ett effektivt sätt att hitta gamla nycklar som säkert kan raderas.

Felsök en integration som inte fungerar som förväntat

När en integration inte fungerar som den ska är den första frågan alltid densamma: kom anropet fram överhuvudtaget? API-loggen ger svaret på några sekunder, och svaret är oberoende av vad leverantören av det andra systemet anser. Gå igenom stegen i ordning.

Steg 1: Kom anropen fram överhuvudtaget?

Öppna loggen för den nyckel som integrationen använder och titta på tidpunkterna under den tidsperiod då något skulle ha hänt.

• Inga rader alls: då ligger problemet i den andra änden. Antingen skickar integrationen inga anrop alls, eller så avvisas den på grund av nyckeln. Kontrollera att den är konfigurerad med rätt nyckel, rätt adress till din webbutik och att nyckeln inte har raderats
• Rader fram till en viss tidpunkt, och sedan ingenting: då slutade integrationen att fungera där. Notera tidpunkten. Det är nästan alltid precis vad du behöver för att hitta orsaken i det andra systemet
• Rad efter rad hela vägen: anropen kommer fram, och felet ligger i vad som anropas. Gå vidare till steg 2

Om du har flera nycklar, se till att du tittar på rätt nyckel. Loggen är per nyckel, och en tom logg betyder bara att just den nyckeln inte har använts.

Steg 2: Träffar anropen rätt sökväg och metod?

Jämför kolumnerna Sökväg och Metod med vad du förväntar dig:

• Om du bara ser GET läser integrationen endast ut data. Om den även ska ändra något saknas POST-anrop (skapa) eller PUT-anrop (uppdatera)
• Om du ser en sökväg som inte finns i API:et är slutpunkten felstavad i konfigurationen. Ett sådant anrop besvaras med 404, men det kan du bara se på sökvägen, eftersom loggen inte visar svarskoder
• Om du ser ”product” där du förväntade dig ”product/123” hämtar integrationen hela listan istället för den enskilda produkten. Det är inte nödvändigtvis ett fel, men det är ofta förklaringen till en hög förbrukning

Sortera efter Sökväg för att samla likadana anrop. Då blir det tydligt om en enda endpoint står för den allra största delen av anropen.

Steg 3: Skickar integrationen rätt parametrar?

Kolumnen ”Parametrar” avslöjar hur integrationen är konfigurerad i praktiken. Typiska saker att titta efter:

• Finns det en last_modified med? Om den saknas hämtar integrationen allt varje gång istället för bara det som har ändrats sedan sist
• Finns det ”limit” och ”offset”, och räknar ”offset” upp som förväntat? Om den fortsätter att vara 0 fastnar integrationen på första sidan och ser aldrig resten av dina data
• Finns det filter som du inte hade räknat med, t.ex. en sökning eller en begränsning av fält?

Kom ihåg att innehållet i POST- och PUT-anrop inte sparas. Loggen kan visa att en uppdatering skickades till produkt 123, men inte vilka värden den innehöll.

Steg 4: Är det rätt avsändare?

Kolumnerna IP och User agent visar vem som använder nyckeln. Om du inte känner igen avsändaren används nyckeln av något annat än du tror, t.ex. ett gammalt testskript, en tidigare leverantör eller en kollega som har kopierat nyckeln. Klicka på IP-adressen för att se allt som just den avsändaren har gjort.

Det är också här du upptäcker om två system delar samma nyckel. Om du ser två olika användaragenter på samma nyckel finns det två system som använder den, och då kan du varken skilja deras användning åt eller stänga av det ena utan att det påverkar det andra. Skapa en nyckel för varje system.

Steg 5: Hur ofta ringer den?

Sortera efter Tidpunkt och titta på avståndet mellan anropen. Körs synkroniseringen var femte minut när den egentligen ska köras en gång i timmen? Kommer det en stor klump av anrop varje natt? Filtrera på en metod eller sök på en endpoint, och använd siffran högst upp på sidan som räknar antalet.

Om det finns betydligt fler anrop än förväntat är det ofta förklaringen till att integrationen når den dagliga gränsen och får 429-fel. Läs mer i artikeln om API-nycklar och dagliga gränser.

Till utvecklare

Inlägget skrivs i det ögonblick nyckeln godkänns, det vill säga innan anropet dirigeras och innan den dagliga gränsen kontrolleras. Det är därför som 403, 404, 405 och 429 förekommer i loggen, medan 401 aldrig gör det. En tom logg är med andra ord i sig själv en användbar signal: antingen nådde anropet inte fram, eller så avvisades det vid autentiseringen.

Eftersom varken statuskod, request-body eller response-body sparas är det en bra idé att logga tidsstämpel, metod, sökväg och frågesträng i din egen klient, så att de två loggarna kan jämföras med varandra. Ange samtidigt en fast, igenkännbar user agent för dina anrop. Det är det enda fältet i loggen som du själv styr, och det gör det enkelt att skilja ditt eget skript från tredjepartsintegrationer, även när de delar samma webbutik.

Det här ska du ha med dig när du skriver till supporten

Om vi ska titta på det går det mycket snabbare om du har följande klart:

• Namnet på den nyckel som integrationen använder. Skicka namnet, inte själva nyckeln
• Exakt tidpunkt för ett anrop som gick fel. Håll muspekaren över tidpunkten i loggen för att få fram datum och klockslag ned till sekunden
• Sökväg och metod för anropet
• Vad du förväntade dig skulle hända, och vad som istället hände

Vanliga frågor

Jag är inte tekniskt kunnig. Behöver jag överhuvudtaget använda API-loggen?

Inte i det dagliga arbetet. Loggen är ett felsökningsverktyg, inte något du behöver hålla koll på. Men det enda du alltid kan använda den till är att se om det överhuvudtaget kommer in några anrop från en integration just nu. Om till exempel din fraktlösning kraschar, öppnar du loggen för dess nyckel och tittar på den översta raden. Om det står ”för 2 dagar sedan” är det den externa tjänsten som har stannat, inte din webbutik. Det svaret räcker ofta för att komma vidare.

Varför kan jag inte se svarskoderna i loggen?

Loggen sparar det inkommande anropet, inte svaret. Om du ska felsöka utifrån felkoder måste du logga svaret i din egen klient. Loggen används för att bekräfta att anropet nådde fram, och för att se vilken sökväg och metod det träffade, samt vilka parametrar det hade med sig. Det finns ett undantag som är värt att känna till: anrop som avvisas med 401 finns inte alls i loggen, så en helt tom logg är i sig ett starkt tecken på att nyckeln är felaktig eller har raderats.

Vårt lagersystem har slutat uppdateras. Vad ska jag göra först?

Gå till Integrationer → API-åtkomst, klicka på Logga ut för lagersystemets nyckel och titta på den översta raden. Om det står ”3 dagar sedan” stannade systemet för tre dagar sedan och felet ligger hos lagersystemet. Om det står ”5 minuter sedan” kommer anropen fram, och då ska du gå vidare till kolumnerna Sökväg och Parametrar. Notera tidpunkten innan du kontaktar leverantören, eftersom det är det första de kommer att fråga om.

Kan jag se en samlad logg för alla nycklar i webbutiken?

Nej, loggen visas per nyckel. Det är just därför det är en bra vana att skapa en nyckel per integration med ett beskrivande namn, t.ex. ”Lagersystem” eller ”Prisvakt”. På sidan för API-åtkomst kan du sortera efter Senast använd och snabbt se vilka nycklar som faktiskt är aktiva, och kolumnen Daglig gräns visar förbrukning och gräns per nyckel. Om du vill jämföra förbrukningen mellan olika nycklar är översikten rätt ställe, inte loggen.

Vårt ekonomisystem har bokfört en order felaktigt. Kan jag se i loggen vad som skickades?

Du kan se att ett anrop skickades, när, med vilken metod och till vilken sökväg, t.ex. ett PUT till order/3658. Själva innehållet sparas inte, så du kan inte se vilka belopp eller konton som ingick. För det måste du använda bilagan eller loggen i ekonomisystemet. Loggen kan däremot fastställa tidpunkten helt exakt, och det räcker oftast för att hitta rätt bokföring i den andra änden.

Loggen visar anrop var femte minut hela natten. Är det ett problem?

Inte i sig, men det är värt att räkna på. Ett anrop var femte minut blir knappt 300 anrop per dygn, och om integrationen hämtar flera sidor åt gången multipliceras siffran. Det räknas in i nyckelns dagliga gräns. Titta på kolumnen Parametrar: om det inte finns något last_modified med hämtar integrationen hela katalogen varje gång, och då är de allra flesta anrop bortkastade. Be leverantören att ändra så att endast ändringar sedan senaste hämtningen hämtas.

Kan jag använda API-loggen som dokumentation gentemot min revisor?

Nej. Posterna raderas automatiskt efter åtta veckor, och loggen innehåller varken belopp eller innehållet i anropen. Den dokumenterar att ett system har gjort ett anrop till din webbutik vid en viss tidpunkt, inte vad som utbyttes. För bokföringsdokumentation måste du använda beställningarna i webbutiken och bilagorna i ekonomisystemet.

Vår prisbevakare säger att de uppdaterar priserna varje timme, men priserna ändras inte. Hur kontrollerar jag det?

Öppna loggen för prisövervakaren och klicka på PUT i kolumnen Metod för att filtrera efter metoden. Om det inte finns några PUT-anrop alls läser tjänsten endast och skriver inte, oavsett vad som står i deras inställningar. Om det finns PUT-anrop till produktstigar varje timme kommer uppdateringarna fram. Kontrollera då först om nyckeln är inställd på Endast läsning, för då avvisas skrivningarna med 403 även om anropen finns i loggen. Om nyckeln är korrekt inställd ska du undersöka om det är rätt produkter som berörs, eller om priserna skrivs över av något annat i efterhand.

Behöver du hjälp med API-integration? Kontakta oss på support@shoporama.dk.