Webhooks #

Webhooks lader Your AI Connector automatisk give besked til dine andre forretningsværktøjer, når der sker noget vigtigt — en ny kontakt oprettes, en aftale bookes, eller en besked modtages. I stedet for manuelt at tjekke for opdateringer, modtager dine forbundne systemer en øjeblikkelig notifikation i det øjeblik, der sker noget.

Hvad er webhooks? #

Tænk på en webhook som en automatisk sms mellem to apps. Når der sker noget i Your AI Connector (f.eks. en ny kontakt tilmelder sig), sender platformen øjeblikkeligt en notifikation til et andet system efter dit valg. Du angiver en webadresse (kaldet en “webhook-URL”), hvor disse notifikationer skal sendes hen — denne leveres typisk af dit CRM, din automatiseringsplatform eller din udvikler.

Webhooks sender kun data UD af Your AI Connector. Et webhook er en ensrettet vej fra Your AI Connector til dine andre værktøjer. Der findes ingen webhook-URL, der sender kundeemner, kontakter eller beskeder IND i platformen. For at skubbe et nyt kundeemne ind — fra en hjemmesideformular, dit CRM eller GoHighLevel — foretager dit system i stedet et API-kald. Se API-adgang (handlingen Opret en kontakt) og Funnels. Det eneste, du skal bruge til den indgående retning, er din API-nøgle, som ligger i sin egen sektion — se API-adgang. Siden Webhooks, der beskrives her, er udelukkende til den udgående retning.

Almindelige anvendelser inkluderer:

• Synkronisering af nye kontakter til dit CRM.
• Udløsning af et workflow i Zapier, Make eller Pabbly, når et tag tilføjes.
• Underretning af dit team i Slack, når et menneske bliver tilkaldt.
• Opdatering af dit kalendersystem, når en aftale bookes.
• Logning af samtaleoversigter til din database.

Opsætning af webhooks #

1. Klik på Indstillinger (tandhjulsikonet) i venstre sidepanel.
2. Under gruppen Integrationer i indstillingspanelet skal du klikke på Webhooks.

På en konto, hvor der endnu ikke er konfigureret nogen webhooks, ser siden således ud:

3. Klik på New webhook øverst til højre. En formular åbnes direkte på siden:

4. Udfyld:
   • Endpoint-URL — den webadresse, som Your AI Connector sender begivenhedsnotifikationer til. Du får denne fra dit eksterne system (CRM, automatiseringsplatform eller egen server).
   • Navn — en etiket, som du kan genkende senere (f.eks. “Slack-advarsler” eller “CRM-synkronisering”). Kun til din egen reference.

Din webhook URL skal være en offentligt tilgængelig https:// adresse. Almindelige http:// adresser, localhost eller adresser på private netværk samt platform-interne adresser afvises, når du gemmer. For at teste fra din egen maskine skal du bruge en offentlig tunnel (webhook.site eller ngrok) i stedet for localhost.

5. Under Events, skal du klikke på de hændelser, som denne webhook skal modtage — alle 22 er angivet i De 22 webhook-hændelser.
6. (Valgfrit) Slå Forsøg igen ved mislykkede leveringer til, hvis du vil have Your AI Connector til at blive ved med at forsøge ved en midlertidig fejl — se Forsøg igen ved mislykkede leveringer.
7. Klik på Opret webhook. Den vises på listen under formularen, og du kan til enhver tid klikke på Test på dens række for at sende en eksempel-payload til dit endpoint.

Tilladelse påkrævet. Tilføjelse, redigering eller test af webhooks kræver “rediger”-tilladelse til Integrationer (teammedlemmer med skrivebeskyttet adgang ser en meddelelse om skrivebeskyttelse i stedet for formularen).

Signering af en webhook kræver, at den allerede er gemt først — åbn en eksisterende webhooks række for at redigere den, så vises panelet Signeringshemmelighed nederst i redigeringsformularen. Et helt nyt, ikke-gemt udkast har endnu ingen signeringsmulighed — se Signerede payloads nedenfor.

Én webhook til alle dine klientkonti (bureauer) #

Hvis du driver et bureau, behøver du ikke at genskabe den samme webhook på hver klientkonto. På bureaukontoen har webhook-formularen en ekstra til/fra-knap: Udløs også for alle klientkonti. Slå den til, og denne webhook modtager også hændelser, der sker på alle klientkonti under dit bureau — ét endpoint, hele bureauet.

Sådan fungerer det:

• user-blokken fortæller dig, hvilken klient en hændelse tilhører. Hver notifikation indeholder allerede en user-blok, der identificerer den konto, hændelsen skete på, så din automatisering kan rute pr. klient.
• Din webhooks egne indstillinger gælder overalt. De hændelser, du har valgt, underskriftshemmeligheden og indstillingen for genforsøg bruges også til leveringer til klientkonti.
• Ingen dobbelte leveringer. Hvis en klientkonto har sin egen webhook, der peger på den samme URL, bruges den i stedet for den konto-hændelser — den samme hændelse ankommer aldrig to gange til ét endpoint.
• Klienter kan ikke se den. Webhooken vises ikke på klientkontoens egen side for webhooks, og klienter kan ikke slå den fra — det er din opgave at administrere den.
• Pålidelighed spores pr. klientkonto. Hvis dit endpoint bliver ved med at fejle, slås det automatisk fra for den konto, hvis leveringer fejlede (se Webhook-pålidelighed), ikke for hele bureauet på én gang.

Til/fra-knappen vises kun på bureaukonti. Det understøttes også at indstille den via API’et — se feltet apply_to_sub_accounts i Webhooks API.

Tilgængelige udløserbegivenheder #

Du kan aktivere eller deaktivere hver af de 22 webhook-hændelser uafhængigt af hinanden. Når en hændelse udløses, sender Your AI Connector en meddelelse til din webhook-URL med de relevante data. Hver hændelse, hvad den betyder, og den event-kode, den placerer i payloaden, er angivet samlet i De 22 webhook-hændelser længere nede på denne side.

Godt at vide: Opgave oprettet, Opgave opdateret og Opgave fuldført kan vælges fuldt ud og gemmes korrekt. Dagligt resumé oprettet er også en ny tilføjelse. Se Webhook for fuldført opgave nedenfor for den payload-struktur.

Tag-baserede webhook-udløsere #

subscribed_to_tags begrænser ikke en webhooks hændelser til et tag. Det indsnævrer kun, hvilke tags der producerer en notifikation om samtaleresumé. For at modtage en anmodning, når et specifikt tag anvendes, skal du indstille en webhook-URL på det pågældende tag under fanen Tags for agenten (eller kampagnen).

Selve webhook-formularen har ingen tag-vælger, hverken når du opretter en ny webhook eller redigerer en eksisterende, så subscribed_to_tags kan kun læses eller ændres via Webhooks API eller ved at kontakte support.

Godt at vide: Redigering af en eksisterende webhook, der har en subscribed_to_tags-liste (omdøbning, ændring af hændelser, aktivering af genforsøg), sletter ikke længere listen — da formularen ikke har nogen tag-vælger, der skal sendes tilbage, efterlader lagring fra denne side den eksisterende liste uberørt. (Dette var en reel fejl før 21. juli 2026: lagring fra webhook-formularen slettede tidligere listen, fordi den altid sendte en tom tag-liste. Hvis en webhook mistede sin subscribed_to_tags-liste før denne dato, skal den konfigureres igen via API’et.)

Generer resumé for taggede kontakter #

Hvor en webhook har en subscribed_to_tags-liste, kan du aktivere Generer resumé. Når det er aktiveret, genererer Your AI Connector automatisk et samtaleresumé for kontakten, når et af disse tags anvendes, og inkluderer det i webhook-dataene — fuld kontekst uden en separat anmodning.

Test af din webhook #

1. Åbn Indstillinger → Integrationer → Webhooks.
2. Klik på Test på din webhooks række.
3. Tjek dit eksterne system for at bekræfte, at det modtog testdataene.
4. Gennemgå dataformatet for at sikre, at dit system kan parse det korrekt.

For en fuld end-to-end-test skal du sende en besked, der ville udløse en af dine konfigurerede hændelser (en udsendelse eller en indgående besked på en forbundet kanal), og bekræfte, at webhooken udløses med de rigtige data.

Hvad tæller som en vellykket levering #

Uanset om du klikker på Test, eller begivenheden udløses i virkeligheden, sender vi det samme:

• En POST-anmodning (aldrig GET), med body som JSON og Content-Type: application/json.
• Overskrifterne oplistet under Signerede payloads. Signaturoverskrifter inkluderes kun, når du har angivet en signeringsnøgle.

Vi betragter leveringen som vellykket, når:

• Dit slutpunkt svarer med enhver 2xx-status (200, 201, 204 — alt er fint).
• Det svarer inden for 30 sekunder.

Et par ting, der overrasker folk:

• Svarskroppen ignoreres. Du behøver ikke at returnere nogen bestemt JSON. En tom 200 er nok.
• Omdirigeringer tæller som en fejl. Vi følger dem ikke, så en 301 eller 302 (inklusive en omdirigering med skråstreg til sidst, eller http til https) registreres som en mislykket levering. Gem den endelige URL, ikke en der omdirigerer.
• Query-strenge understøttes fuldt ud. https://your-app.com/hook?token=abc123 sendes præcis som du gemte den, så det fungerer lige så godt at placere et token i query-strengen som at placere det i stien.
• Din URL skal være https:// og offentligt tilgængelig. Adresser, der tilhører Your AI Connector's egen infrastruktur, afvises, men dine egne endpoints på Google Cloud Functions, Cloud Run, App Engine, Firebase Hosting eller andre steder er fine.
• En firewall eller et bot-beskyttelseslag foran dit endpoint kan blokere os. Det mest almindelige tilfælde er Cloudflare: hvis din zone har Bot Fight Mode eller en administreret udfordring slået til, får vores anmodning en “Just a moment…”-udfordringsside med en 403 i stedet for at nå din server — og en server-til-server-anmodning kan aldrig bestå en browser-udfordring, så både Test-knappen og rigtige hændelser fejler på samme måde. Test-knappen fortæller dig, når dette sker (“Cloudflare viser en bot-udfordring til vores anmodning”). Løs det i Cloudflare med en Security / WAF-regel, der springer udfordringer over for din webhook-sti (eller for Webhook-Delivery/1.0 user agent), og klik derefter på Test igen.
• Hvis din firewall i stedet har brug for en IP-tilladelsesliste (for eksempel Cloudflares gratis abonnement, hvor almindelig Bot Fight Mode ikke kan springes over med en WAF-regel, men en IP Access Rule indstillet til Allow kører før den), kan vi hjælpe: hver levering, uanset om den kommer fra Test-knappen eller en live-hændelse, sendes fra én fast IPv4-adresse (ingen intervaller, ingen IPv6, ingen rotation). Kontakt support, så giver vi dig adressen, der skal på tilladelseslisten. Behold signaturverificering som din faktiske tillidskontrol, da den validerer hver payload uanset hvor den kom fra.
• Testresultatet fortæller dig præcis, hvad dit endpoint svarede. En mislykket test viser nu den virkelige årsag (den HTTP-status dit endpoint returnerede, en timeout, eller at vi slet ikke kunne nå adressen) i stedet for en generisk fejl, og en test på en gemt webhook sendes signeret, når signering er slået til, præcis som en live-hændelse.

Brug af n8n, Make eller Zapier (“Test-URL” vs “Produktions-URL”) #

Automationsplatforme giver dig normalt to forskellige webhook-adresser, og det forvirrer ofte folk:

• En Test-URL (i n8n indeholder den /webhook-test/). Denne modtager kun data, mens du aktivt overvåger lærredet og lige har klikket på Listen for test event (eller Test workflow). Den fanger en enkelt hændelse og stopper derefter med at lytte – så hvis du klikker på Test i Your AI Connector flere gange i træk, fanges kun den første, og kun hvis lyttevinduet er aktivt i det præcise øjeblik. For at teste: Klik først på Listen for test event i n8n, vend derefter tilbage til Your AI Connector og klik på Test én gang.
• En Produktions-URL (i n8n indeholder den /webhook/, ingen -test). Dette er den, du skal indsætte i Your AI Connector til live-hændelser. Den virker kun, når dit workflow er sat til Aktivt. Hvis workflowet ikke er aktivt, afviser n8n anmodningen med en “404 / webhook not registered”-fejl, selvom Your AI Connector sendte dataene korrekt.

Kort sagt: test med Test-URL’en, mens du lytter, men for at webhooken skal fortsætte med at virke på rigtige kontakter, skal du gemme Produktions-URL’en i Your AI Connector og sikre dig, at workflowet er Active.

Webhook-dataformat #

Når en webhook udløses, sender Your AI Connector strukturerede data (JSON) til din webhook-URL. Hvis du bruger en automatiseringsplatform som Zapier eller Make, parser den automatisk disse data for dig. Hvis du bygger en brugerdefineret integration:

{
  "event": "contactCreated",
  "contact": { "id": "<contact-id>", "first_name": "Jane", "...": "..." },
  "campaign": { "id": "<campaign-id>", "name": "AI Receptionist", "status": "Live" },
  "agent": { "id": "<agent-id>", "name": "Front Desk" },
  "user": { "id": "<account-id>", "email": "owner@example.com" }
}

campaign eller agent — normalt den ene, ikke begge. Hvis din konto bruger agenter, er dine kontakter tilknyttet en agent frem for en kampagne, så campaign ankommer som null, og agent fortæller dig, hvem der håndterede den. Ældre kampagnebaserede konti ser det omvendte. Læs det felt, der er udfyldt; antag ikke, at campaign altid er til stede.

agent-blokken ankom den 15. august 2026. Den findes sammen med campaign i begivenheder knyttet til en samtale – en afsluttet chat, forstyr ikke, en genoptagelse, en de-arkivering, en AI-pause, en ny besked, et samtaleressumé og den webhook, du kan indstille på et tag – og indeholder den håndterende agents id og name, eller null, når ingen agent er involveret. Den er rent additiv: alle felter, du allerede modtager, er uændrede, så en modtager, du har bygget før denne dato, fortsætter med at fungere uden behov for opdateringer.

Nogle hændelser tilføjer deres egen ekstra blok på øverste niveau. For eksempel tilføjer Appointment Booked en appointment-blok (se Appointment Booked Webhook), New Message tilføjer en fuld message-blok med teksten (se New Message Webhook), og Deliveries og Reads tilføjer en kort message-blok med kun beskedens ID og status (se Deliveries and Reads Webhook).

Deliveries og Reads fortæller dig hvilken besked, men ikke hvad den sagde. De indeholder en message-blok med beskedens id og status — og det id er det samme messageId, som send message endpoint returnerer, så du kan matche en leverings- eller læsekvittering med den præcise besked, du sendte — men ingen beskedtekst. Replies indeholder slet ingen message-blok. Hvis du har brug for ordene, der blev sendt eller modtaget, skal du abonnere på New Message ved siden af dem.

To ting du skal vide, før du skriver din modtager. Der er intet timestamp-felt og ingen data-wrapper. Hver blok ligger på øverste niveau i JSON-objektet, som vist ovenfor.

De 22 webhook-hændelser #

De 22 webhook-hændelser med den visningsetiket, du markerer i appen, og den event-kode, der sendes i payloaden. event-koden er en kort streng, der ikke matcher visningsetiketten, så match din modtager på koden, ikke etiketten:

To koder mere optræder aldrig på den liste, fordi du ikke abonnerer på dem: contact_tags_updated, sendt af en webhook-URL indstillet på et individuelt tag, og summary_generated, sendt når et chatresumé skrives for et tag i en webhooks subscribed_to_tags-liste.

Kanal forbundet sendes endnu ikke. Den optræder på listen over hændelser, men intet udsender den i dag. Byg ikke noget baseret på den.

Tag-baserede og opgave-notifikationer bruger deres egne separate former. Se Contact Tags Updated og Task Completed.

Webhook for oprettet kontakt #

Sendes når hændelsen Kontakt oprettet udløses (en ny kontakt tilføjes manuelt, via import eller via API).

Hændelsesnavn #

contactCreated

Payload-format #

{
  "event": "contactCreated",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "human_alert_reason": null,
    "is_bot_active": true,
    "ad_referral": null
  },
  "campaign": {
    "id": "<campaign-id>",
    "name": "AI Receptionist",
    "status": "Live"
  },
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  }
}

“Test”-eksemplet og en rigtig hændelse ser lidt forskellige ud. Testknappen sender pladsholderdata (John Doe, en eksempelkampagne). En rigtig “Kontakt oprettet”-hændelse indeholder kontaktens faktiske detaljer, og nogle felter kan være tomme afhængigt af kanalen.

Webhook for ny besked #

Denne webhook udløses hver gang en besked tilføjes til en samtale, på en hvilken som helst kanal. Den dækker begge retninger: beskeder din kontakt sender dig, og beskeder din AI, dit team eller en kampagne sender dem. Det er den eneste webhook, der inkluderer beskedteksten, så det er den, du skal bruge, når du vil spejle samtaler i et eksternt system.

Hændelsesnavn #

new_message

Payload-format #

{
  "event": "new_message",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "human_alert_reason": null,
    "is_bot_active": true,
    "ad_referral": null
  },
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  },
  "message": {
    "id": "<message-id>",
    "body": "Hi, are you open on Saturday?",
    "direction": "inbound",
    "status": "received",
    "created_at": "2026-07-30T17:27:06.000Z",
    "channel": "whatsapp_web"
  }
}

Der er stadig ingen campaign-blok i denne payload. New Message sender contact, agent, user og message. agent-blokken blev tilføjet den 15. august 2026 og fortæller dig, hvilken agent der håndterer samtalen; hvis du også har brug for kampagnekontekst, kan du slå kontakten op via API’en ved hjælp af contact.id.

Interne AI-poster udløser ikke denne webhook. Ved siden af rigtige beskeder holder platformen sine egne bogføringsrækker i en samtale (AI’ens værktøjskald og interne tur-poster). Disse sendes aldrig — du modtager kun beskeder, der rent faktisk blev sendt eller modtaget.

Deliveries and Reads Webhook #

Disse to hændelser rapporterer, hvad der skete med en besked, efter den forlod Your AI Connector: Deliveries udløses, når en besked når kontakten (eller fejler), og Reads udløses, når kontakten åbner den, på de kanaler, der understøtter læsekvitteringer.

Begge indeholder en message-blok med ID’et på den besked, hændelsen handler om, så du kan matche opdateringen med den præcise besked, du sendte.

Hændelsesnavne #

delivered og undelivered for Deliveries, read for Reads.

Payload-format #

{
  "event": "delivered",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "ad_referral": null
  },
  "campaign": {
    "id": "<campaign-id>",
    "name": "AI Receptionist",
    "status": "Live"
  },
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  },
  "message": {
    "id": "<message-id>",
    "status": "delivered"
  }
}

Sådan matcher du en opdatering med den besked, du sendte. Gem det messageId, du får tilbage, når du sender en besked via API’et. Når en Deliveries- eller Reads-notifikation ankommer, skal du slå det gemte ID op mod message.id i payloaden — det er din leverings- eller læsekvittering for den præcise besked.

Der er ingen beskedtekst her. message-blokken indeholder kun ID’et og status. Abonner på New Message, hvis du også har brug for selve indholdet.

message-blokken er kun til stede, når vi ved, hvilken besked det var. Ved de sjældne opdateringer, vi ikke kan knytte til en gemt besked, udelades blokken helt i stedet for at blive sendt tom — så tjek at message eksisterer, før du læser message.id.

Én notifikation pr. statusændring. En enkelt udgående besked producerer normalt en delivered-notifikation og derefter, på kanaler med læsekvitteringer, en read-notifikation. En mislykket afsendelse producerer undelivered i stedet.

Appointment Booked Webhook #

Udløses når en kontakt booker en aftale. Den udløses på samme måde, uanset om AI’en bookede den under en samtale, du bookede den manuelt, eller den kom ind via API’et.

Hændelsesnavn #

booked

Payload-format #

{
  "event": "booked",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith"
  },
  "campaign": {
    "id": "<campaign-id>",
    "name": "AI Receptionist",
    "status": "Live"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com"
  },
  "appointment": {
    "appointment_id": "<appointment-id>",
    "start_time": "2026-07-20T15:00:00.000Z",
    "end_time": "2026-07-20T15:30:00.000Z",
    "status": "confirmed",
    "room_name": "Room 1",
    "description": "Discovery call",
    "summary": "30 min intro",
    "google_calendar_event_id": null,
    "event": {
      "id": "<service-id>",
      "event_name": "Intro Call",
      "slot_duration": 30,
      "location": "Zoom",
      "meeting_link": "https://...",
      "event_type": "online"
    }
  }
}

google_calendar_event_id er ofte null i denne webhook, og det er normalt. Google Calendar-hændelsen oprettes i samme øjeblik, som denne notifikation sendes ud, så ID’et er normalt ikke klar endnu. Hent aftalen igen via dens appointment_id et øjeblik senere, hvis du har brug for det. Den forbliver null permanent, hvis kontoen ikke har en forbundet Google Calendar, så vent ikke på den for evigt.

“Test”-knappen inkluderer ikke appointment-blokken. Brug den til at bekræfte, at dit endepunkt svarer, og foretag derefter én rigtig booking for at se den fulde payload.

To tilfælde, hvor denne webhook ikke udløses: aftaler importeret fra en ekstern kalender og bookinger, der kommer ind via Formitable-integrationen.

Webhook for opdaterede kontakt-tags #

Udløses, når et tag anvendes på en kontakt, og det pågældende tag har en webhook-URL konfigureret på den agent eller kampagne, som kontakten tilhører.

Hændelsesnavn #

contact_tags_updated

Hvornår den udløses #

• Et tag anvendes på en kontakt, der har en tildelt agent, en tildelt kampagne eller begge dele.
• Mindst ét af de anvendte tags har en webhook-URL angivet under fanen Tags for den pågældende agent eller kampagne.

Hvis kontakten har begge dele, og kampagnens tags indeholder webhook-URL’er, vinder disse; ellers bruges agentens.

Hvis flere tags med forskellige webhook-URL’er anvendes i samme opdatering, sendes én anmodning pr. URL, hvor hver anmodning kun indeholder de tags, der er knyttet til den pågældende URL.

Fjernelse af et tag sender aldrig en anmodning. De fleste peger disse URL’er mod en handling — indsamling af et depositum, booking af en tid, underretning af en medarbejder — så et tag, der fjernes fra en kontakt, blev tidligere brugt til at køre handlingen igen. Det kan det ikke længere. En fjernelse vises stadig i removed_tags, når den sker i samme opdatering som en tilføjelse, der går til den samme URL, så en automatisering, der læser begge arrays, bevarer det fulde overblik; hvad den aldrig vil se, er en anmodning forårsaget af en fjernelse alene. (Ændret 12. august 2026. Før denne dato sendte fjernelser også en anmodning.)

Payload-format #

{
  "event": "contact_tags_updated",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "is_bot_active": true,
    "ad_referral": {
      "ctwa_clid": "ARAbc123...",
      "source_id": "120210000000000",
      "source_type": "ad",
      "source_url": "https://fb.me/xxxx",
      "headline": "Get 20% off today",
      "body": "Message us now to claim your discount",
      "channel": "whatsapp"
    }
  },
  "added_tags": ["qualified-lead"],
  "removed_tags": ["new-lead"],
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  }
}

Test af en tag-webhook #

Ved siden af webhook-URL-feltet under fanen Tags findes en Test-knap. Den sender straks en eksempel-payload til den pågældende URL, så du kan bekræfte, at din automatisering modtager den, før du venter på en rigtig samtale.

Testen sender den samme contact_tags_updated-form, som er vist ovenfor, ved hjælp af en pladsholder-kontakt, med det tag du tester i added_tags og et tomt removed_tags. Det, din automatisering ser i testen, er det, den vil se i produktion.

To ting du skal vide:

• Gem tagget først. Testen slår tagget op via dets gemte navn, så et helt nyt tag eller en ikke-gemt omdøbning kan ikke testes endnu. Knappen forbliver grå, indtil navnet på skærmen matcher det gemte.
• En mislykket test tæller ikke mod din webhook. Tests bidrager aldrig til den automatiske deaktivering efter gentagne fejl, som beskrevet i Webhook-pålidelighed.

Hvis testen fejler, fortæller beskeden dig, hvad dit slutpunkt svarede (for eksempel en 404 eller 500), hvilket normalt er nok til at finde en forkert URL eller et workflow, der ikke er slået til.

Webhook for fuldført opgave #

Kun til reference. Opgave-webhooks (som data) er dokumenteret her for udviklere; hændelserne Opgave oprettet, Opgave opdateret og Opgave fuldført kan vælges på listen over standardhændelser i webhook-formularen ligesom enhver anden hændelse — se Tilgængelige udløserhændelser og De 22 webhook-hændelser.

Denne payload sendes, når en opgave skifter til et stadie, der er markeret som et fuldførelsesstadie. En opgave, der flyttes mellem stadier, der ikke er fuldførelsesstadier, sender i stedet taskUpdated-formatet.

Hændelsesnavn #

taskCompleted

Hvornår den udløses #

• En opgave opdateres.
• Dens stage-værdi er ændret i forhold til dens tidligere værdi.
• Det nye stadie er konfigureret som et fuldførelsesstadie i kontoens indstillinger for opgavestadier.

Payload-format #

{
  "event": "taskCompleted",
  "contact": {
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "human_alert_reason": null
  },
  "user": {
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  },
  "message": {
    "id": "<task-id>",
    "title": "Follow up with Jane",
    "description": "Confirm pricing and send proposal",
    "type": "follow_up",
    "priority": "high",
    "stage": "<stage-id>",
    "due_date": "2026-01-20T15:00:00Z",
    "source": "ai",
    "source_detail": "<source-detail>",
    "campaign_id": "<campaign-id>",
    "linked_human_alert": "<human-alert-id>",
    "tags": ["qualified-lead"],
    "notes": "Customer requested a callback"
  }
}

Slå en webhook fra (eller slet den) #

Hver webhook har en tænd/sluk-knap direkte på sin række. Hvis du slår en webhook fra, stopper den med at modtage hændelser, men alt, hvad du har konfigureret, bevares — URL’en, hændelserne og eventuelle signaturhemmeligheder. Slå den til igen, og den fortsætter, hvor den slap; intet af det, der skete, mens den var slået fra, leveres efterfølgende.

Brug den, når du ønsker, at leveringer skal stoppe i et stykke tid: dit endpoint er ved at blive genopbygget, du debugger en støjende integration, eller du sætter en automatisering på pause.

Sletning af en webhook (papirkurvsikonet på dens række) fjerner den permanent, inklusive dens signaturhemmelighed. Hvis du kun ønsker at stoppe leveringer, skal du i stedet slå den fra — sletning er til, når du er helt færdig med slutpunktet.

Dette er ikke det samme som at en webhook slås automatisk fra. Hvis vi deaktiverer din webhook efter gentagne fejl (se Webhook-pålidelighed), vil kontakten ovenfor ikke aktivere den igen. Når dit endpoint er rettet, skal du redigere webhooken og gemme den med en ændret URL (enhver ændring af URL’en genaktiverer den), eller kalde genaktiverings-endpointet via API’et — eller spørg supporten, så aktiverer vi den for dig.

Signerede payloads (Verificering af, at en webhook rent faktisk kommer fra os) #

Enhver, der får kendskab til din webhook-URL, kan sende en falsk anmodning til den. Hvis du reagerer automatisk på webhooks — f.eks. ved opdatering af fakturering eller oprettelse af CRM-poster — giver aktivering af signering dig mulighed for at verificere, at hver anmodning rent faktisk kommer fra os.

Signering er valgfri og deaktiveret som standard, og du aktiverer den pr. webhook fra den pågældende webhooks redigeringsvisning (åbn rækken for et gemt webhook).

Aktivering af signering #

1. Åbn webhooken (Indstillinger → Integrationer → Webhooks → klik på rækken for din webhook).
2. I sektionen Signeringshemmelighed skal du klikke på Generer.
3. Kopiér hemmeligheden (den starter med whsec_) og gem den i dit modtagende system. Behandl den som en adgangskode.

Du kan altid vende tilbage og afsløre, kopiere, rotere eller deaktivere hemmeligheden fra dette samme panel.

Hvad vi sender #

Når signering er aktiveret, indeholder hver levering for den webhook disse to ekstra HTTP-headere:

Disse tre er med i hver levering, uanset om de er signerede eller ej:

Sådan verificerer du #

Signaturen er en HMAC-SHA256 af strengen <timestamp>.<raw request body>, hvor din signeringshemmelighed bruges som nøgle.

Verificer mod den rå anmodningstekst — de nøjagtige bytes, du modtog. Hvis dit framework parser JSON-koden og serialiserer den igen før kontrol, kan bytes ændre sig, og signaturen vil ikke matche.

Node.js-eksempel:

const crypto = require("crypto");

function verify(rawBody, headers, secret) {
  const timestamp = headers["x-webhook-timestamp"];
  const signature = headers["x-webhook-signature"]; // "v1=<hex>"

  // Reject anything older than 5 minutes so a captured request can't be replayed later.
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return false;

  const expected = crypto.createHmac("sha256", secret).update(`${timestamp}.${rawBody}`).digest("hex");

  return crypto.timingSafeEqual(Buffer.from(signature.replace("v1=", "")), Buffer.from(expected));
}

Python-eksempel:

import hashlib, hmac, time

def verify(raw_body: bytes, headers, secret: str) -> bool:
    timestamp = headers["X-Webhook-Timestamp"]
    signature = headers["X-Webhook-Signature"].replace("v1=", "")

    # Reject anything older than 5 minutes so a captured request can't be replayed later.
    if abs(time.time() - int(timestamp)) > 300:
        return False

    expected = hmac.new(secret.encode(), f"{timestamp}.".encode() + raw_body, hashlib.sha256).hexdigest()

    return hmac.compare_digest(signature, expected)

Sammenlign signaturer med en timing-sikker funktion (timingSafeEqual / compare_digest), ikke ==. Det koster intet og undgår en subtil klasse af angreb.

Roter hemmeligheden #

Klik på Roter for at udskifte hemmeligheden. Skiftet sker øjeblikkeligt: den næste levering signeres kun med den nye hemmelighed. Hvis dit endpoint er aktivt, bør du acceptere både den gamle og den nye hemmelighed i et par minutter, mens du udruller den nye.

Hvis du slår signering fra, stopper det blot afsendelsen af signatur-headere.

Genforsøg af fejlede leveringer #

Som standard genforsøges en levering, der fejler, ikke — hvis dit system er nede i det øjeblik, går den begivenhed tabt.

Slå Forsøg mislykkede leveringer igen til på en webhook (i opret/rediger-formularen), så bliver vi ved med at prøve:

Det strækker sig over cirka 2 timer og 40 minutter, så en webhook kan overleve et vedligeholdelsesvindue eller et kort nedbrud hos dig.

Hvad genforsøges: midlertidige problemer — hvis din server returnerer en 5xx-fejl, en timeout eller en forbindelsesfejl.

Hvad der ikke gør: hvis dit endpoint selv afviser anmodningen (enhver 4xx-fejl), forsøger vi ikke igen — at sende den identiske anmodning igen ville kun resultere i den samme afvisning.

Hvilke hændelser forsøges igen: tag-webhooks (contact_tags_updated), de tre opgavehændelser og det daglige resumé. Resten sendes én gang, så for dem har kontakten intet at handle på. Hver hændelse bærer stadig X-Webhook-Delivery, så én deduplikeringsregel dækker dem alle.

Slå kun genforsøg til, hvis dit endpoint er idempotent. Genforsøg betyder, at den samme hændelse kan ankomme mere end én gang. Brug X-Webhook-Delivery-headeren til at genkende en gentagelse: den forbliver den samme på tværs af alle forsøg for én hændelse, så du sikkert kan ignorere et ID, du allerede har håndteret.

Genforsøg interagerer med den automatiske deaktivering efter gentagne fejl (se Webhook-pålidelighed) på den måde, du ønsker: fejl-tælleren tæller en hel levering, først efter at hvert genforsøg er opbrugt – ikke hvert enkelt forsøg.

Webhook-pålidelighed #

• Your AI Connector sender webhooks over en sikker forbindelse (HTTPS). Sørg for, at den webadresse, du angiver, bruger HTTPS.
• Hvis dit system returnerer en fejl, betragtes leveringen som mislykket.
• Overvåg dit modtagende systems oppetid for at undgå at gå glip af begivenheder.
• For kritiske arbejdsgange bør du slå Forsøg mislykkede leveringer igen til og overveje en fallback-mekanisme.

Webhooks slås automatisk fra efter gentagne fejl. Hvis din webhook-URL fejler gentagne gange (ca. 5 fejl i træk, eller 3 i træk ved konfigurationsfejl), stopper Your AI Connector automatisk med at sende hændelser til den URL. For at aktivere den igen, når dit endpoint er sundt: rediger webhooken og gem den med en ændret URL (enhver ændring af URL’en genaktiverer den), eller brug genaktiverings-endpointet via API’et — det er ikke nok at gemme den igen med den samme URL. Supporten kan også genaktivere den for dig.

Fejlfinding #

Næste skridt #

• GoHighLevel-integration — brug webhooks til at integrere Your AI Connector med GHL.
• API-adgang — kombiner webhooks med API’et for kraftfuld automatisering.
• Brug af tags til at mærke kontakter — opsæt tags, der udløser dine webhooks.