Hva er webhooks?

Webhooks gjør det mulig å varsle systemet ditt automatisk når produktdata endres. I stedet for å spørre jevnlig om det har skjedd noe, oppgir du et HTTP-endepunkt som mottar et JSON-kall hver gang et produkt opprettes, oppdateres eller slettes.


Slik fungerer det

  1. En produkthendelse inntreffer (opprettet, oppdatert eller slettet).
  2. Aktive webhooks sjekkes mot hendelsestype og eventuelle filtre.
  3. Matchende hendelser samles opp og sendes ut omtrent hvert 30. sekund.
  4. En HTTP POST med JSON-kropp sendes til endepunktet ditt.
  5. Hvis leveringen mislykkes, gjøres det nytt forsøk opptil 3 ganger. Vedvarende feil registreres og kan utløse e-postvarsler.

Sette opp en webhook

Gå til Integrasjoner → Webhooks i menyen. Klikk +-knappen nederst til høyre for å opprette en webhook.

Felter

Navn En etikett for å identifisere denne webhookens.

URL Endepunktet på din side som vil motta POST-kall.

Hendelser Hvilke typer endringer som skal utløse webhookens. Du kan velge én eller flere:

Autentiseringsmetode Hvordan systemet autentiserer seg når det kaller endepunktet ditt. Alternativer:

E-post for feilvarsel Hvis leveringen gjentatte ganger mislykkes, sendes feilmeldinger til denne adressen.

Aktivering

En webhook må aktiveres eksplisitt før den begynner å sende. Når den er aktiv, er URL, hendelsestyper, autentiseringsinnstillinger og varslings-e-post låst - deaktiver først hvis du trenger å endre dem.

Testing

Bruk Test konfigurasjon-knappen for å sende en eksempelnyttelast til endepunktet ditt umiddelbart. Dialogen viser nyttelasten som vil bli sendt, og svaret endepunktet ditt returnerer. Dette er den enkleste måten å verifisere oppsettet på før aktivering.


Filtre

Som standard utløses en webhook ved alle endringer som samsvarer med dens hendelsestyper. Filtre lar deg begrense dette slik at du bare mottar kall for bestemte typer endringer.

For å legge til et filter, åpne webhookens og klikk +-knappen i filterpanelet. Et filter krever et endringsområde - hvilken del av produktdataene som ble endret:

EndringsområdeHva det dekker
ProduktKjerneproduktfelt (navn, status, leverandør osv.)
AttributtProduktattributtverdier
MediaMediefiler lagt til eller fjernet
RelasjonProduktrelasjoner
ETIMETIM-klasse eller verdiendringer
EmballasjeEmballasjedata
StrukturProduktstruktur og hierarki
EPDEPD-data
EntitetEntitetstilknytninger

For Produkt-endringer kan du i tillegg angi hvilket felt som må ha endret seg (f.eks. kun utløse ved statusendring, ikke navneendring).

For Attributt-endringer kan du angi et bestemt attributt ved navn.

Flere filtre kombineres med OR - en webhook utløses hvis ett av filtrene matcher.


Nyttelast

Kallet sendes som POST med Content-Type: application/json. Kroppen ser slik ut:


{ "identifier": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "data": null, "events": [ { "type": "CREATED", "timestamp": "2026-05-10T08:00:00Z" }, { "type": "UPDATED", "field": "NAME", "timestamp": "2026-05-11T14:30:00Z" } ] }
FeltBeskrivelse
identifierProduktets offentlige ID (UUID). Bruk denne til å hente produktet fra API-et.
dataAlltid null for øyeblikket. Fullstendige produktdata vil inkluderes i en fremtidig versjon.
eventsAlle hendelser som har skjedd på dette produktet siden forrige levering. Kan inneholde mer enn én.
events[].typeCREATED, UPDATED eller DELETED
events[].fieldFor UPDATED-hendelser på kjerneproduktfelt: én av PRODUCT_NO, ALT_PRODUCT_NO, NAME, ALT_NAME, STATUS_ID, TYPE_ID, OWNER_ID, GROUP_ID, SUPPLIER_ID, BASE_ID, IS_BASE, VARIANTS. Utelates for CREATED/DELETED og for alle andre endringstyper (attributter, media, relasjoner osv.).
events[].timestampISO-8601-tidsstempel for når hendelsen inntraff.

Flere hendelser kan samles i ett enkelt kall. Behandle alle oppføringer i events-arrayen.

Siden data for øyeblikket er null, bør mottakeren bruke identifier til å hente gjeldende produkttilstand fra API-et ved behov.


Krav til mottaker

Endepunktet ditt må:


Feilvarslinger

Hvis levering mislykkes etter alle forsøk, registreres feilen internt. Hvis en notificationEmail er konfigurert, sendes en oppsummerings-e-post hvert 6. time så lenge det finnes uløste feil. Feilregistreringer beholdes i 14 dager.