Generelt
Prduct API er en REST API, og dataformatet er JSON.
Hvor starter jeg?
API-dokumentationen findes i Swagger. Den viser:
Alle tilgængelige endpoints
Required parameters
Request og response formats
Validation rules
Authentication requirements
Dokumentationen skal bruges som den tekniske reference, mens denne FAQ forklarer den overordnede struktur og logik.
Base URL og versionering
API’en bruger versionerede endpoints.
I sandbox testes typisk med:
/api/v1/...
Alle endpoints i dokumentationen er relative til denne base.
Authentication
De fleste endpoints kræver authentication med en Bearer token.
Du skal medtage header:
Authorization: Bearer <token>
Hvis token mangler eller er ugyldig, får du en 401 error.
Implementér sikker token-håndtering og eventuelt refresh-logik. Læs mere
Hvordan er API struktureret?
API’en er organiseret omkring flere hovedkoncepter:
Attributes – genanvendelige metadatafelter
Industries og Categories – klassificering og taksonomi
Data Models – templates som bestemmer hvordan documents er struktureret
Documents – de centrale forretningsobjekter
EUDR endpoints – specialiserede API’er til EUDR-compliance
I praksis arbejder integrationer typisk med at create, update og sync documents, som refererer til attributter og andre entities.
Pagination
List endpoints bruger cursor-based pagination.
Responsen indeholder typisk:
data– selve recordslinks– pagination linksmeta– metadata
For at hente flere resultater:
Læs
links.nextBrug det som
cursori næste request
Antallet af items per page styrer du med per_page (typisk 1–1000).
Implementér altid cursor pagination — API’en bruger ikke page numbers.
Identifiers: external_id
De fleste objekter understøtter external_id.
Dette er din egen system identifier (f.eks. fra ERP, PIM, CRM osv.).
Best practice:
Brug
external_idsom primær reference keyHold den konsistent på tværs af synkroniseringer
Brug den frem for interne Prduct IDs
Når du linker leverandører, kunder, produkter osv., bør du bruge external_id.
Dette gør integrationer mere robuste og vedligeholdelsesvenlige.
Bulk operations
API’en understøtter bulk create af documents.
Bulk endpoints er nyttige når du:
Importerer store datamængder
Kører scheduled sync jobs
Onboarder nye kunder
Ved brug af bulk:
Håndtér partielle failures
Log validation errors
Forvent ikke at alle items lykkes
Hver item valideres separat.
EUDR endpoints
EUDR endpoints hjælper med compliance-relaterede workflows og data.
De bruges til:
Purchase documents
Sale documents
Batches og sub-batches
Locations
Due diligence statements
Kendetegn:
Supporter partial updates
Tillader linking med
external_idSupporter nested batch structures
Bevarer eksisterende data hvis ikke overskrevet
Brug EUDR endpoints når du bygger eller vedligeholder EUDR-dokumentation.
Anbefalet integration flow
Et typisk integrationsflow ser sådan ud:
Sæt authentication op og test access
Hent reference data (industries, categories, attributes)
Verify eller create required attributes
Configure data models hvis nødvendigt
Implementér document create og update med
external_idImplementér EUDR workflows hvis relevante
Implementér pagination for alle list-kald
Tilføj logging, retries og error handling
Denne rækkefølge reducerer validation errors og rework.
Retningslinjer for en stabil integration
For langsigtet stabilitet bør du:
Altid bruge external_id som primær update key
Implementér cursor pagination
Håndtér translatable felter korrekt
Validate payloads før sending
Log alle failed requests
Behandl 422 errors som data-quality issues
Brug bulk for store datasæt
Test i sandbox før production
Typiske spørgsmål og svar
Hvordan paginerer jeg results?
Brug værdien fra links.next som cursor og styr side size med per_page.
Hvorfor får jeg “is translatable” fejl?
Feltet skal sendes inde i translations[].attributes, ikke i top-level attributes.
Hvordan linker jeg suppliers, customers eller products?
Brug deres external_id når du refererer til dem.
Hvilken identifier skal jeg bruge?
Brug external_id som din primære identifier og hold den stabil.
Hvornår skal jeg bruge bulk endpoints?
Ved store imports, onboarding og schedulere sync jobs.
Typiske errors og deres årsager
Error | Forklaring | Løsning |
403 Forbidden | Manglende permissions/token | Tjek API keys og bruger-permissions |
422 Name is required to create locations | locations bruges uden eksisterende location document | Fjern locations med mindre du importerer med GPS |
405 Method Not Allowed (PUT /documents) | PUT uden document ID | Brug URL med document_id |
PUT error on translations | PUT understøtter ikke translation object | Brug translation endpoint |
Jeg får fejlen The type field is required…
Denne fejl kan komme af:
Type-feltet er ikke korrekt udfyldt
Forkert endpoint bruges
Du forsøger at sende HTML/text uden JSON Bearer token
→ Tilføj-ContentType 'application/json'til body
Jeg får fejlmeddelelsen: "The selected data_model_id is invalid."
Det betyder, at systemet ikke kan identificere den datamodel, der er angivet i body’en på en request eller response. Dette gælder ikke kun for datamodel-endpointet, men for alle endpoints, der bruger et datamodel-ID.
Sådan løses det: Du kan fjerne data_model_id eller angive et gyldigt ID.
Hvorfor sker det? Det sker ofte, når man flytter fra sandbox til produktion, hvis datamodellerne ikke er blevet synkroniseret i de generelle indstillinger. Sørg derfor for, at datamodellerne er ens i sandbox- og production/live-miljøet.
Hvordan ved jeg om en attribut skal være i "translation" eller ej?
Attributter med translation er defineret på den enkelte attribut om de kan indeholde en translation. Nogle standard attributter, som eks. beskrivelsen og HS-coden er altid i translation. Andre som eks. Identifier er ikke.
Ved oprettelsen af Custom attributter, vælges om en attribut er translatable eller ej. Dette valg afgører, hvor attributten skal placeres i dit request kald. Hvis du er i tvivl kan du altid gå ind og redigere attributten for at se dens indstillinger (findes under "Datamodeller" menuen og scroll ned til sektionen "Custom attributter".
Jeg får en ukendt fejl?
En del fejl kan skyldes at din Json ikke er valid, det kan ofte være et komma for meget eller for lidt. Her anbefaler vi en sprogmodel, evt. i kombination med vores dokumentation for at fejlfinde.
Jeg får fejlen “hs_code is translatable”
Nogle felter i prduct er defineret som translatable fields og kan ikke sendes direkte i attributes.
Hvis du fx prøver:
},
"attributes": {
"hs_code": "XXXXXX"
},
Så får du:
"message": "hs_code is translatable"
Det skyldes systemstrukturen. HS-koden er en liste af objekter under translations.
Din request skal derfor se sådan ud:
"translations": [
{
"attributes": {
"hs_code": [
{"value": "XXXXXX"}
]
}
}
]
Support og spørgsmål
Hvis du støder på problemer eller har spørgsmål, kan du:
Bruge chatbotten i nederste højre hjørne
Sende email til [email protected]