Konfigurer webhooks

Published: 16. juli 2026 · Last updated: 21. juli 2026 · By Marcus Biel

Webhooks lar Maildroppa varsle en annen applikasjon når noe viktig skjer i kontoen din.

I stedet for gjentatte ganger å spørre Maildroppa om en abonnent er opprettet, oppdatert, avmeldt eller tildelt en tagg, kan applikasjonen din motta en HTTPS-forespørsel kort tid etter at hendelsen inntreffer.

Webhooks-siden er det sentrale stedet for denne kontoomfattende integrasjonen. Du kan opprette flere endepunkter, velge hvilke hendelser hvert endepunkt mottar, legge til autentiseringshoder, teste tilkoblingen, kontrollere leveringsforsøk og spille av en produksjonshendelse på nytt ved behov.

Slik fungerer webhooks for kontoer

En webhook for en konto følger denne prosessen:

1. En hendelse oppstår i Maildroppa, for eksempel at en abonnent opprettes.
2. Maildroppa finner alle aktive endepunkter som abonnerer på denne hendelsen.
3. Maildroppa oppretter én levering for hvert samsvarende endepunkt.
4. JSON-nyttelasten signeres med kontoens webhook Signing secret.
5. Maildroppa sender en HTTPS POST-forespørsel til den lagrede URL-en for endepunktet.
6. Endepunktet ditt bekrefter signaturen, lagrer eller behandler hendelsen og returnerer et HTTP-svar.
7. Maildroppa registrerer resultatet i leveringshistorikken og prøver automatisk på nytt ved midlertidige feil.

Hvis flere endepunkter abonnerer på samme hendelse, mottar hvert endepunkt sin egen levering. Forretningshendelsen har samme Event ID for alle, mens hver levering har sin egen Delivery ID.

Webhooks for kontoer skiller seg fra trinnet «Send a webhook» i en Automation. Webhooks for kontoer lytter etter valgte konto­hendelser på tvers av Maildroppa. En Automation-webhook sendes bare når en abonnent når det aktuelle trinnet. Begge bruker kontoens webhook Signing secret, så en rotering av hemmeligheten påvirker alle utgående webhook-mottakere som bekrefter Maildroppa-signaturer.

Åpne Webhooks-siden

Åpne «Settings», utvid «Developers» og velg «Webhooks».

Siden inneholder tre hovedområder:

• Signing secret
• Endpoints
• Delivery history for det valgte endepunktet

Når du har mer enn ett endepunkt, velger du en endepunktsrad for å vise Delivery history. Hvis du ikke har valgt ett uttrykkelig, viser Maildroppa historikken for det første endepunktet i listen.

Før du oppretter et endepunkt

Gjør klar en mottaker på serveren din før du konfigurerer Maildroppa. Mottakeren bør:

• Være tilgjengelig via en offentlig HTTPS-URL.
• Godta POST-forespørsler med en application/json-kropp.
• Bevare den rå forespørselskroppen til Maildroppa-signaturen er bekreftet.
• Returnere en 2xx-status først etter at hendelsen er trygt mottatt.
• Behandle gjentatte leveringer idempotent ved å bruke Event ID.
• Svare raskt i stedet for å utføre langsomt arbeid under forespørselen.

Et pålitelig mønster er å bekrefte forespørselen, lagre Event ID og nyttelasten i en varig kø eller database, returnere 200 eller 204 og behandle forretningshandlingen etterpå.

Ikke eksponer en utviklingsdatamaskin, en lokal nettverksadresse eller et ubeskyttet skript som produksjonsmottaker for webhooks. Maildroppa godtar bare offentlige HTTPS-mål og kontrollerer målet på nytt når en levering sendes.

Trinn 1: Generer Signing secret

Alle webhook-forespørsler fra Maildroppa signeres. Mottakeren bruker Signing secret til å bekrefte at forespørselen ble opprettet av Maildroppa, og at kroppen ikke ble endret underveis.

Øverst på siden viser Signing secret-panelet én av disse statusene:

• Missing — Det finnes ingen Signing secret ennå.
• Ready — En Signing secret er konfigurert.
• Loading — Maildroppa henter gjeldende status.

Klikk på «Generate secret» når statusen er Missing.

Maildroppa viser den nye hemmeligheten umiddelbart. Den begynner med whsec_. Klikk på «Copy» og lagre den i den hemmelighetsbehandleren eller den beskyttede miljøkonfigurasjonen som mottakeren bruker.

Hele verdien vises bare umiddelbart etter generering eller rotering. Når du laster inn siden på nytt eller forlater den, viser Maildroppa bare at det finnes en hemmelighet og når den sist ble oppdatert. Den viser ikke den lagrede hemmeligheten igjen.

Hvis du mister hemmeligheten

Hvis mottakeren ikke lenger har den gjeldende hemmeligheten, klikker du på «Rotate secret» og lagrer den nye verdien som vises.

Rotering erstatter den forrige hemmeligheten umiddelbart. Maildroppa beholder ikke begge verdiene i en overgangsperiode. Oppdater alle mottakere som bruker denne konthemmeligheten før du sender flere tester eller stoler på produksjonsleveringer.

Nye leveringer, planlagte forsøk på nytt, tester og avspillinger signeres med den gjeldende hemmeligheten på tidspunktet for HTTP-forespørselen. Det betyr at en levering som ble opprettet før roteringen, fortsatt kan signeres med den nye hemmeligheten når den forsøkes sendt etterpå.

Behandle hemmeligheten som et passord

Ikke plasser Signing secret i nettleserkode, et offentlig repositorium, en URL, en feilmeldingsside eller en vanlig applikasjonslogg.

Bare mottakeren på serversiden trenger hemmeligheten. Hvis du tror at den er avslørt, roterer du den og oppdaterer alle mottakere umiddelbart.

Bekrefte en webhook-signatur

Hver forespørsel inneholder disse Maildroppa-headerne:

• X-Maildroppa-Event-Id — Identifiserer forretningshendelsen.
• X-Maildroppa-Delivery-Id — Identifiserer denne bestemte leveringen.
• X-Maildroppa-Timestamp — Signeringstidspunktet som Unix-sekunder.
• X-Maildroppa-Signature — Den versjonerte HMAC-signaturen.

Maildroppa sender også:

• Content-Type: application/json
• User-Agent: Maildroppa-Webhooks/1.0

Signaturen har dette formatet:

v1=<lowercase hexadecimal HMAC>

Maildroppa oppretter den med HMAC-SHA256. Det signerte innholdet er tidsstempelet, etterfulgt av et punktum, etterfulgt av den nøyaktige rå JSON-forespørselskroppen:

<timestamp>.<raw request body>

Bruk Signing secret som HMAC-nøkkel.

Følgende Node.js-eksempel viser det grunnleggende bekreftelsestrinnet. rawBody må være de opprinnelige forespørselsbytene, ikke JSON som allerede er analysert og serialisert på nytt.

import crypto from 'node:crypto';

export function verifyMaildroppaWebhook({ rawBody, timestamp, signature, signingSecret }) {
  const signedPayload = Buffer.concat([Buffer.from(`${timestamp}.`, 'utf8'), rawBody]);

  const expectedSignature = `v1=${crypto
    .createHmac('sha256', signingSecret)
    .update(signedPayload)
    .digest('hex')}`;

  const received = Buffer.from(signature, 'utf8');
  const expected = Buffer.from(expectedSignature, 'utf8');

  return received.length === expected.length && crypto.timingSafeEqual(received, expected);
}

Etter at signaturen er bekreftet, må du også sammenligne tidsstempelet med servertiden din. Avvis forespørsler utenfor en kort toleranse som er valgt for infrastrukturen din, for eksempel fem minutter. Dette reduserer risikoen for at en fanget, gyldig forespørsel spilles av mye senere.

Analyser og behandle JSON først etter at begge kontrollene er bestått.

Vanlige årsaker til signaturfeil

En signatur mislykkes vanligvis av én av disse grunnene:

• Mottakeren bruker en gammel hemmelighet etter rotering.
• Middleware analyserte eller endret JSON før signaturen ble beregnet.
• Mottakeren signerer bare kroppen og utelater <timestamp>..
• Tidsstempelet behandles som en formatert dato i stedet for den nøyaktige headerv­erdien.
• v1=-prefikset utelates fra sammenligningen.
• Den beregnede HMAC-en kodes på en annen måte enn som heksadesimale tegn med små bokstaver.

Logg Event ID og Delivery ID når bekreftelsen mislykkes, men logg aldri Signing secret eller sensitive verdier i egendefinerte headere.

Trinn 2: Legg til et endepunkt

Klikk på «Add endpoint» i Endpoints-delen.

Redigeringsverktøyet består av fire deler:

• Endpoint URL
• Events
• Custom headers
• Active status

Nye endepunkter starter som Active, og alle hendelsene som vises i redigeringsverktøyet, er valgt i utgangspunktet. Gå gjennom utvalget før du lagrer, slik at mottakeren bare får varslene den faktisk trenger.

Konfigurere URL-en for endepunktet

Skriv inn den fullstendige offentlige URL-en som skal motta Maildroppa-forespørsler, for eksempel:

https://integrations.example.com/webhooks/maildroppa

URL-en må oppfylle disse kravene:

• Den må bruke https://.
• Den må inneholde et gyldig offentlig vertsnavn.
• Den kan være opptil 2 048 tegn lang.
• Den kan ikke inneholde malvariabler med { eller }.
• Den kan ikke inneholde brukernavn eller passord før vertsnavnet.
• Den kan ikke inneholde et URL-fragment som begynner med #.
• Den må bruke standard HTTPS-port 443.
• Den kan ikke bruke localhost, en rå IP-adresse eller et vertsnavn som løser seg til et blokkert privat eller reservert nettverk.

Spørringsparametere støttes, men ikke legg API-nøkler eller andre hemmeligheter i URL-en. URL-er er synlige i endepunktlisten og leveringsdataene. Bruk en Custom header for legitimasjon i stedet.

Maildroppa følger ikke omdirigeringer. Lagre det endelige HTTPS-målet i stedet for en URL som returnerer 301, 302, 307 eller 308.

Vertsnavnet for målet løses på nytt før sending. Et vertsnavn som senere løser seg til en privat eller blokkert adresse, avvises selv om det var gyldig da endepunktet ble lagret.

Velge hendelser

Velg minst én hendelse. Et endepunkt mottar bare hendelsestypene som er valgt i redigeringsverktøyet.

Siden tilbyr disse hendelsesvalgene:

Subscriber Created — subscriber.created

Sendes når en abonnent opprettes i Maildroppa-kontoen.

Bruk denne hendelsen til å opprette den tilsvarende kontakten i et CRM-system, en kundedataplattform, en intern database eller et annet system som tar hensyn til samtykker.

Ikke tolk denne hendelsen som bevis på at hver påmelding har fullført Double Opt-in. Abonnentstatusen i nyttelasten beskriver den gjeldende tilstanden.

Subscriber Updated — subscriber.updated

Sendes når innebygd abonnentinformasjon eller verdier i egendefinerte felt endres.

Bruk hele abonnentobjektet i nyttelasten som den gjeldende Maildroppa-representasjonen. Unngå å anta at bare én bestemt egenskap ble endret.

Taggtildelinger og -fjerninger har egne hendelsestyper, slik at de kan håndteres separat.

Subscriber Unsubscribed — subscriber.unsubscribed

Sendes når abonnenten går over til statusen unsubscribed gjennom en avmeldingshandling.

Bruk denne hendelsen til å undertrykke kontakten i tilkoblede systemer. Ikke abonner personen automatisk på nytt fordi et annet system fortsatt markerer kontakten som aktiv.

Tag Added — subscriber.tag_added

Sendes når en tagg tildeles en abonnent.

Nyttelasten inneholder abonnenten og taggen som er involvert i denne bestemte endringen.

Tag Removed — subscriber.tag_removed

Sendes når en tagg fjernes fra en abonnent.

Nyttelasten inneholder den oppdaterte abonnenten og den fjernede taggen. Den fjernede taggen oppgis separat selv om den ikke lenger finnes i abonnentens gjeldende tags-array.

Form Submitted — form.submitted

Sendes når en besøkende sender inn et Maildroppa-påmeldingsskjema.

Behandle dette som et signal om skjemainnsending, ikke som bekreftelse på at Double Opt-in er fullført. Alle arbeidsflyter som krever et bekreftet abonnement, må fortsatt respektere abonnentens gjeldende status og bekreftelsesprosessen.

Bruk separate endepunkter når ansvaret er forskjellig

Du kan sende ulike hendelser til ulike systemer. For eksempel:

• Send abonnent- og tagghendelser til et CRM-system.
• Send avmeldingshendelser til en undertrykkelsestjeneste.
• Send skjemainnsendelser til en analysepipeline.

Separate endepunkter reduserer unødvendig trafikk og gjør feil enklere å diagnostisere. Hvert endepunkt har sitt eget hendelsesutvalg, sin egen URL, egne egendefinerte headere, aktiv status, tester og Delivery history.

Legge til egendefinerte headere

Egendefinerte headere er valgfrie. Bruk dem når mottakeren krever en API-nøkkel, et bearer-token, en tenant-identifikator eller en annen fast header.

Klikk på «Add header» og skriv deretter inn Header name og Header value. Egnede eksempler er:

Authorization: Bearer your-token

X-Integration-Key: your-secret-key

Du kan legge til opptil 20 egendefinerte headere.

Headernavn:

• Er obligatoriske.
• Kan inneholde opptil 128 tegn.
• Må bruke gyldige tegn for HTTP-headernavn.
• Må være unike uten hensyn til store og små bokstaver.

Headerv­erdier:

• Er obligatoriske.
• Kan inneholde opptil 2 000 tegn.
• Kan ikke inneholde linjeskift.

Følgende navn er reserverte og kan ikke erstattes av en egendefinert header:

• Content-Type
• Content-Length
• Host
• User-Agent
• Alle navn som begynner med X-Maildroppa-

Dette hindrer at en egendefinert verdi erstatter Maildroppas leverings- og signaturheadere.

Slik lagres hemmeligheter i headere

Maildroppa krypterer verdier i egendefinerte headere før de lagres. Lagrede verdier returneres ikke til nettleseren i lesbart format.

Når du redigerer endepunktet senere, viser verdifeltet «Stored value kept». La feltet stå tomt når den eksisterende hemmeligheten skal beholdes. Skriv inn en ny verdi for å erstatte den.

Hvis du endrer headernavnet, må du skrive inn verdien på nytt. Maildroppa beholder bare en lagret hemmelighet så lenge det opprinnelige headernavnet er uendret.

Hvis du fjerner en header­rad, fjernes denne headeren fra fremtidige leveringer etter at endepunktet er lagret.

Verdier i egendefinerte headere behandles som sensitive i lagrede forespørselsopplysninger. De maskeres i stedet for å vises i Delivery history.

Angi endepunktet som aktivt eller inaktivt

La «Active» være valgt når endepunktet er klart til å motta hendelser umiddelbart.

Fjern valget når du vil lagre konfigurasjonen uten å starte leveringer. Du kan aktivere endepunktet senere fra endepunktlisten.

Et inaktivt endepunkt:

• Mottar ikke nye hendelser.
• Kan ikke sende en Test webhook.
• Forblir synlig og redigerbart.
• Beholder sin eksisterende Delivery history.

Aktivering av et endepunkt fyller ikke inn hendelser som oppstod mens det var inaktivt.

Klikk på «Save» når URL, hendelsesutvalg, headere og status er riktige.

Forstå endepunktlisten

Hver endepunktsrad viser:

• Destinasjons-URL-en.
• Et Active- eller Inactive-merke.
• De abonnerte hendelsestypene.
• Antallet egendefinerte headere.
• Tidspunktet da endepunktet sist ble oppdatert.

De tilgjengelige handlingene er:

• On/Off — Aktiverer eller deaktiverer endepunktet.
• Test — Sender én umiddelbar testforespørsel til et aktivt endepunkt.
• Edit — Endrer URL, hendelser, headere eller aktiv status.
• Delete — Fjerner endepunktkonfigurasjonen permanent etter bekreftelse.

Velg hoveddelen av en rad for å åpne Delivery history for dette endepunktet under listen.

Slik påvirker lagrede endringer eksisterende leveringer

En konto­hendelse oppretter en levering med et øyeblikksbilde av endepunktets URL, nyttelast og egendefinerte headere på det tidspunktet.

Redigering av URL eller egendefinerte headere påvirker nye leveringer. En levering som allerede ligger i kø, beholder sin opprinnelige destinasjon og lagrede headerkonfigurasjon.

Endring av de valgte hendelsene påvirker også bare hendelser som oppstår etterpå. Maildroppa oppretter ikke leveringer retroaktivt for hendelsestyper som ikke var valgt da hendelsen oppstod.

Signing secret er annerledes: Den leses når HTTP-forespørselen klargjøres. En ventende levering eller avspilling kan derfor bruke en nylig rotert Signing secret selv om nyttelasten og øyeblikksbildet av endepunktet ble opprettet tidligere.

Teste et endepunkt

Klikk på «Test» for et aktivt endepunkt etter at mottakeren og Signing secret er klare.

Maildroppa sender umiddelbart én signert forespørsel med den lagrede URL-en for endepunktet og de lagrede egendefinerte headerne. Ulagrede endringer i et åpent redigeringsverktøy er ikke en del av testen.

Testnyttelasten bruker hendelsestypen webhook.test og setter livemode til false:

{
  "id": "evt_test_example",
  "type": "webhook.test",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": false,
  "data": {
    "message": "This is a test webhook from Maildroppa."
  }
}

De genererte ID-ene og tidsstempelet er forskjellige for hver reelle test.

En test gjør nøyaktig ett HTTP-forsøk. Testleveringer legges ikke inn i produksjonens tidsplan for nye forsøk og kan ikke spilles av på nytt.

Når forespørselen er ferdig, viser resultatpanelet:

• Test success eller Test failed
• Event ID
• HTTP-status når et svar ble mottatt
• Varighet
• Delivery ID
• Feilinformasjon når tilgjengelig
• Et svarutdrag når mottakeren returnerte en kropp

Testen vises også i Delivery history med et Test-merke. Bruk «Test»-filteret for å vise bare testforespørsler.

Forstå produksjonsnyttelasten

Produksjonshendelser for kontoer bruker en felles JSON-konvolutt:

{
  "id": "evt_example",
  "type": "subscriber.created",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": true,
  "data": {}
}

Egenskapene på toppnivå betyr:

• id — Event ID. Samsvarer med X-Maildroppa-Event-Id.
• type — Hendelsesnøkkelen som er valgt i redigeringsverktøyet for endepunktet.
• schema_version — Versjonen av nyttelastskjemaet. Bruk den når du avgjør hvordan hendelsen skal analyseres.
• created_at — Tidspunktet da hendelsesnyttelasten ble opprettet, i UTC.
• livemode — true for produksjonshendelser og false for testhendelser.
• data — Det hendelsesspesifikke innholdet.

Ruting av hendelser skal bruke den nøyaktige type-verdien. Ignorer tilleggsegenskaper integrasjonen din ikke trenger, slik at kompatible utvidelser av nyttelasten ikke ødelegger mottakeren.

Nyttelast for abonnenthendelser

Abonnenthendelser inneholder den gjeldende abonnentrepresentasjonen i data.subscriber:

{
  "id": "evt_example",
  "type": "subscriber.updated",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": true,
  "data": {
    "subscriber": {
      "id": "7f49d0e9-77d6-4c24-8b90-12c9d53d82cc",
      "email": "alex@example.com",
      "first_name": "Alex",
      "status": "active",
      "registered_at": "2026-07-15T08:15:00Z",
      "fields": [
        {
          "id": "b6594e58-0c4b-4138-9ad8-fc4747e076eb",
          "personalization_tag_name": "company",
          "value": "Example Ltd."
        }
      ],
      "tags": [
        {
          "id": "c69af5de-39d3-42a4-8f55-ddf86d10a51c",
          "name": "Customers"
        }
      ]
    }
  }
}

fields og tags er arrayer. De kan være tomme. En abonnentegenskap kan også være null når det ikke finnes noen verdi, så mottakeren bør følge nyttelastskjemaet i stedet for å anta at alle valgfrie profilverdier finnes.

Nyttelast for tagghendelser

Tagghendelser inneholder både abonnenten og taggen som forårsaket hendelsen:

{
  "id": "evt_example",
  "type": "subscriber.tag_added",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": true,
  "data": {
    "subscriber": {
      "id": "7f49d0e9-77d6-4c24-8b90-12c9d53d82cc",
      "email": "alex@example.com",
      "first_name": "Alex",
      "status": "active",
      "registered_at": "2026-07-15T08:15:00Z",
      "fields": [],
      "tags": []
    },
    "tag": {
      "id": "c69af5de-39d3-42a4-8f55-ddf86d10a51c",
      "name": "Customers"
    }
  }
}

For subscriber.tag_removed identifiserer data.tag fortsatt den fjernede taggen, selv om abonnentens gjeldende tags-array ikke lenger inneholder den.

Event ID, Delivery ID og idempotens

Event ID og Delivery ID har ulike formål.

Event ID

Event ID identifiserer forretningshendelsen. Den vises i:

• Nyttelastens id-egenskap på toppnivå.
• Forespørselsheaderen X-Maildroppa-Event-Id.
• Delivery history.

Den samme hendelsen kan sendes til flere abonnerte endepunkter. Disse leveringene deler Event ID.

Forsøk på nytt og manuelle avspillinger beholder også den opprinnelige Event ID. Lagre behandlede Event ID-er og gjør forretningshandlingen idempotent, slik at en gjentatt forespørsel ikke oppretter duplikatkontakter, gjentar en irreversibel handling eller bruker samme endring to ganger.

Delivery ID

Delivery ID identifiserer én leveringspost. Den vises i:

• Forespørselsheaderen X-Maildroppa-Delivery-Id.
• Delivery history.

Hver endepunktslevering har sin egen Delivery ID. En manuell avspilling oppretter en ny Delivery ID, samtidig som den opprinnelige Event ID beholdes.

Bruk Delivery ID til teknisk sporing og brukerstøtte. Bruk Event ID til deduplisering på forretningsnivå.

Returnere riktig HTTP-svar

Maildroppa klassifiserer svar på følgende måte:

• Alle 2xx-svar markerer leveringen som vellykket.
• 408 Request Timeout, 429 Too Many Requests og 5xx-svar er midlertidige feil og kan forsøkes på nytt.
• Nettverksfeil som kan være midlertidige, forsøkes på nytt.
• Omdirigeringer og andre 3xx-svar følges ikke og behandles som endelige feil.
• Andre 4xx-svar behandles som endelige feil og forsøkes ikke på nytt.

Returner 200, 202 eller 204 bare når hendelsen er trygt mottatt. Hvis behandlingen tar tid, lagrer du hendelsen først og returnerer et vellykket svar før det langsommere arbeidet utføres asynkront.

Ikke returner en omdirigering til en annen webhook-URL. Konfigurer den endelige URL-en i Maildroppa i stedet.

Automatisk tidsplan for nye forsøk

Produksjonsleveringer kan gjøre opptil sju HTTP-forsøk.

Etter en feil som kan forsøkes på nytt, planlegger Maildroppa neste forsøk med disse intervallene:

1. Etter forsøk 1: 1 minutt
2. Etter forsøk 2: 5 minutter
3. Etter forsøk 3: 30 minutter
4. Etter forsøk 4: 2 timer
5. Etter forsøk 5: 12 timer
6. Etter forsøk 6: 24 timer

Hvis forsøk 7 fortsatt får en feil som kan forsøkes på nytt, blir leveringen Dead, og det planlegges ikke flere automatiske forsøk.

Tidsplanen måles fra de enkelte mislykkede forsøkene. Det faktiske leveringstidspunktet kan bli litt senere fordi leveringer behandles asynkront og også er underlagt systemets beskyttelsesgrenser.

Løs et midlertidig problem hos mottakeren før det viste tidspunktet for «Next retry» når det er mulig. Hvis de automatiske forsøkene er avsluttet, bruker du Replay etter at mottakeren er frisk igjen.

Forstå Delivery history

Delivery history tilhører det valgte endepunktet. URL-en for endepunktet vises i seksjonsoverskriften, slik at du kan bekrefte hvilken historikk du ser på.

Bruk disse filtrene:

• All — Viser produksjons- og testleveringer.
• Production — Viser bare aktive hendelsesleveringer.
• Test — Viser bare manuelle tester.

Klikk på «Refresh» for å hente den nyeste statusen. Historikken trenger ikke å stå åpen mens Maildroppa sender eller prøver en levering på nytt.

Siden viser de 50 nyeste samsvarende leveringene for det valgte filteret.

Leveringskolonner

Hver rad inneholder:

• Created — Når leveringsposten ble opprettet.
• State — Pending, Success, Failed eller Dead.
• HTTP — Svarstatus, antall forsøk, varighet og tidspunktet for neste forsøk når det er aktuelt.
• Subscriber — Abonnentens e-postadresse når hendelsen er knyttet til en abonnent.
• Delivery — Hendelsestype, Event ID og Delivery ID.
• Actions — Replay når leveringen er kvalifisert.

Hvis ingen HTTP-forespørsel ble sendt, viser HTTP-kolonnen «No HTTP attempt». Dette kan skje når Maildroppa avviser forespørselen før sending, for eksempel fordi Signing secret mangler eller den lagrede destinasjonen ikke lenger kan brukes på en trygg måte.

Når det er tilgjengelig, viser raden også en Error og et Response excerpt som mottakeren returnerte. Ikke returner hemmeligheter eller sensitive personopplysninger i en webhook-responskropp, fordi deler av dette svaret kan vises i kontoens leveringslogg.

Leveringstilstander

Pending betyr at leveringen venter på sitt første forsøk eller et planlagt nytt forsøk. «Next retry» vises når et nytt forsøk er planlagt.

Success betyr at mottakeren returnerte et 2xx-svar. Det er ikke nødvendig med flere automatiske forsøk.

Failed betyr at leveringen endte med et problem som ikke kan forsøkes på nytt, ble avvist før et HTTP-forsøk eller ble stoppet før den kunne sendes.

Dead betyr at alle automatiske forsøk for et problem som kan forsøkes på nytt, ble brukt uten at et vellykket svar ble mottatt.

Lagring av historikk

Leveringsposter beholdes i en begrenset periode:

• Vellykkede produksjonsleveringer: 30 dager
• Mislykkede produksjonsleveringer: 90 dager
• Dead-produksjonsleveringer: 90 dager
• Testleveringer: 30 dager

Behold egne integrasjonslogger når du trenger en lengre revisjonshistorikk. Lagre Event ID-er og Delivery ID-er, men unngå å lagre hemmeligheter unødvendig.

Spille av en levering på nytt

Klikk på «Replay» når en fullført produksjonslevering skal forsøkes på nytt.

Replay er tilgjengelig for produksjonsleveringer med tilstanden Success, Failed eller Dead. Det er ikke tilgjengelig mens en levering er Pending, og testleveringer kan ikke spilles av på nytt.

En avspilling:

• Oppretter en ny Pending-levering.
• Oppretter en ny Delivery ID.
• Beholder den opprinnelige Event ID.
• Beholder den opprinnelige hendelsestypen og JSON-nyttelasten.
• Bruker det opprinnelig lagrede mål-URL-en og øyeblikksbildet av egendefinerte headere.
• Bruker den gjeldende Signing secret når den nye forespørselen klargjøres.

Replay bygger ikke nyttelasten på nytt fra abonnentens gjeldende data. Den sender det opprinnelige hendelsesøyeblikksbildet på nytt. Dette gjør avspillingen etterprøvbar og hindrer at en historisk hendelse endrer betydning uten at det merkes.

Bare én avspilling av samme kildel­evering kan være Pending om gangen. Vent til avspillingen er ferdig før du ber om en ny.

Kontroller at endepunktet er Active før du spiller av på nytt. Hvis endepunktet er inaktivt, kan den kølagte avspillingen ikke leveres på en vellykket måte.

Fordi en mottaker kan ha fullført forretningshandlingen selv om Maildroppa ikke mottok det vellykkede svaret, kan en avspilling føre til en duplikatforespørsel. Deduplisering med Event ID beskytter det tilkoblede systemet mot å gjenta handlingen.

Redigere et endepunkt

Klikk på «Edit» for å endre URL, hendelsesutvalg, egendefinerte headere eller aktiv status.

Før du lagrer:

1. Bekreft at den nye URL-en allerede er tilgjengelig.
2. La lagrede headerv­erdier stå tomme når de skal beholdes uendret.
3. Skriv inn en ny verdi for alle headere som har fått nytt navn.
4. Gå gjennom hendelsesutvalget, slik at nødvendige varsler ikke fjernes ved et uhell.
5. Lagre og send en ny Test webhook.

Husk at kølagte leveringer beholder sitt eksisterende URL- og headerøyeblikksbilde. Test den nye konfigurasjonen for fremtidige leveringer i stedet for å anta at den endrer en eldre forespørsel i køen.

Deaktivere et endepunkt

Bruk On/Off-bryteren når du vil sette en integrasjon på pause uten å slette konfigurasjonen og historikken.

Når et endepunkt slås av:

• Kølegges ikke nye hendelser for det.
• Ventende leveringer som ikke allerede er tatt i bruk for sending, merkes som Failed.
• Test deaktiveres.
• Endepunktet er fortsatt tilgjengelig for redigering og senere aktivering.

En forespørsel som allerede pågår når deaktiveringen skjer, kan fortsatt fullføres. Kontroller Delivery history etter at du har slått endepunktet av hvis dette skillet er viktig for integrasjonen din.

Hendelser som ble mistet mens endepunktet var inaktivt, fylles ikke inn når du slår det på igjen.

Slette et endepunkt

Klikk på «Delete» og bekreft advarselen når endepunktet ikke lenger skal eksistere.

Sletting fjerner endepunktet fra siden, stopper fremtidige hendelsesleveringer og mislykkes for ventende leveringer som ikke allerede er tatt i bruk for sending.

Delete er ikke en måte å sette noe midlertidig på pause på. Bruk On/Off-bryteren når du kanskje trenger konfigurasjonen eller den synlige historikken igjen.

Før sletting bør du notere Event ID-er eller Delivery ID-er du fortsatt trenger i integrasjonsrevisjonen.

Feilsøking

Endepunktet kan ikke lagres

Kontroller at:

• URL-en begynner med https://.
• URL-en bruker et offentlig vertsnavn og port 443.
• URL-en ikke inneholder variabler, påloggingsinformasjon eller fragment.
• Minst én hendelse er valgt.
• Alle Custom header-feltene har et unikt navn og en verdi.
• Reserverte Maildroppa- og HTTP-headere ikke brukes som egendefinerte navn.

Test er deaktivert

Test er bare tilgjengelig for et Active-endepunkt. Slå endepunktet på, eller rediger det og velg «Active». Lagre deretter før du tester.

Testen viser ingen HTTP-forespørsel

Generer en Signing secret hvis statusen er Missing. Kontroller også om vertsnavnet for målet er offentlig og fortsatt løser seg riktig.

En forespørsel kan avvises før sending når hemmeligheten, URL-en, de egendefinerte headerne eller sikkerhetskontrollen av målet er ugyldig.

Mottakeren returnerer 401 eller 403

Kontroller det lagrede Custom header-navnet og legitimasjonen. Rediger endepunktet og skriv inn verdien på nytt hvis den er endret.

Kontroller også at mottakeren ikke forveksler sin egen API-legitimasjon med Maildroppa-signaturen. En egendefinert Authorization-header og X-Maildroppa-Signature har ulike formål og kan kontrolleres uavhengig av hverandre.

Mottakeren returnerer en omdirigering

Maildroppa følger ikke omdirigeringer. Bytt ut URL-en for endepunktet med den endelige offentlige HTTPS-URL-en og test på nytt.

Signaturen samsvarer ikke

Bekreft at mottakeren:

• Bruker den gjeldende Signing secret.
• Bruker den nøyaktige verdien fra X-Maildroppa-Timestamp.
• Signerer <timestamp>.<raw request body>.
• Bruker HMAC-SHA256 og heksadesimal utdata med små bokstaver.
• Sammenligner hele verdien, inkludert v1=.
• Utfører sammenligningen før JSON-analyse endrer kroppen.

Den samme hendelsen kommer mer enn én gang

Dette kan skje etter et nettverksavbrudd, et nytt forsøk eller en manuell avspilling. Det er normalt at leveringssystemer for webhooks tilbyr levering minst én gang i stedet for nøyaktig én gang.

Bruk Event ID som idempotensnøkkel. Returner et 2xx-svar når en allerede behandlet Event ID mottas på nytt og ingen ekstra handling er nødvendig.

En levering er Pending

Se på «Next retry» i HTTP-kolonnen. Et nytt forsøk på en 408, 429, 5xx eller en midlertidig nettverksfeil forblir Pending frem til neste planlagte forsøk.

Klikk på «Refresh» etter tidspunktet for forsøket for å laste inn den nyeste statusen.

En levering er Dead

Alle automatiske forsøk er brukt opp. Løs problemet hos mottakeren først, kontroller at endepunktet er Active, send en Test webhook og bruk deretter Replay på produksjonsleveringen.

Anbefalt sjekkliste for produksjon

Før du stoler på et endepunkt i produksjon, må du bekrefte alt dette:

1. Mottakeren bruker en stabil offentlig HTTPS-URL med et gyldig sertifikat.
2. Signing secret lagres utenfor kildekoden.
3. Signaturen kontrolleres mot den uendrede rå kroppen.
4. Gamle tidsstempler avvises i henhold til en dokumentert toleranse.
5. Mottakeren lagrer og dedupliserer Event ID-er.
6. Mottakeren logger Event ID-er og Delivery ID-er for sporing.
7. Langsom behandling skjer etter at hendelsen er varig mottatt.
8. Et 2xx-svar returneres bare for mottatte hendelser.
9. Egendefinerte legitimasjonsopplysninger lagres i headere, ikke i URL-en.
10. Bare nødvendige hendelsestyper er valgt.
11. En Test webhook lykkes og vises riktig i Delivery history.
12. Overvåkingen varsler deg når produksjonsleveringer begynner å returnere feil.

Med disse sikkerhetstiltakene på plass tilbyr Webhooks-siden begge sider av en pålitelig integrasjon: sikker hendelseslevering til applikasjonen din og en tydelig operasjonell historikk i Maildroppa.