Brugerdefinerede funktioner #

Brugerdefinerede funktioner gør det muligt for din AI-bot at oprette forbindelse til andre systemer under live-samtaler. I stedet for at sige “Jeg tjekker det og vender tilbage til dig”, kan botten slå en ordrestatus op, tjekke lagerbeholdningen eller oprette en post i dit CRM (customer relationship management-system - den software, du bruger til at spore kundeemner og kunder, såsom HubSpot eller Salesforce) - alt sammen i realtid, mens kunden venter.

Brugerdefinerede funktioner vs. Webhooks #

Dette er det mest almindelige punkt for forvirring, så det er værd at få afklaret, før du bygger noget.

Hvornår skal man vælge hvad: Hvis du bare har brug for at fortælle et andet system, at der er sket noget, skal du bruge en webhook - en automatiseret envejsbesked sendt til et andet system (se Indstillinger → Integrationer → Webhooks). Hvis botten skal lære noget fra et andet system, før den fortsætter samtalen, skal du bruge en brugerdefineret funktion.

Eksempler på hvad brugerdefinerede funktioner muliggør #

Fordi svaret føres tilbage i samtalen, åbner brugerdefinerede funktioner op for ting, som webhooks simpelthen ikke kan:

• Live Shopify- eller WooCommerce-lagertjek — Før botten giver kunden et tilbud, tjekker den lagerbeholdningen i realtid og svarer “Ja, vi har 12 på lager i størrelse M” i stedet for “lad mig tjekke det og vende tilbage til dig.”
• Dynamisk prissætning fra et Google Sheet — Dit salgsteam opdaterer priserne i et ark; botten læser den nyeste række midt i samtalen og oplyser den aktuelle pris, uden at nogen behøver at røre ved AI-konfigurationen.
• Voice-AI callback-agent — Når botten kvalificerer et lead, udløser den en stemmeagent (f.eks. en ElevenLabs-drevet opkalder) til at ringe til leadet tilbage inden for få minutter, og bekræfter over for kunden: “fint, forvent et opkald inden for de næste 5 minutter.”
• Brugerdefineret tilbuds-PDF, genereret og sendt via e-mail midt i chatten — Botten indsamler krav, kalder din tilbudsbygger, får et PDF-link tilbage og fortæller kunden: “Jeg har lige sendt dit tilbud via e-mail — tjek din indbakke.”

Hvad kan brugerdefinerede funktioner gøre? #

Tænk på brugerdefinerede funktioner som noget, der giver din bot superkræfter ud over bare at chatte. Her er eksempler fra den virkelige verden:

• Ordresporing - En kunde spørger “Hvor er min ordre?”, og botten tjekker dit e-handelssystem og svarer med forsendelsesstatus og sporingslink
• Lagertjek - “Har I denne i størrelse 10?” Botten tjekker dit lagersystem og giver et svar i realtid
• CRM-opdateringer - Når botten kvalificerer et lead, opretter eller opdaterer den automatisk en post i HubSpot, Salesforce eller et hvilket som helst andet CRM
• Tilbudsgenerering - Botten indsamler kundens krav og genererer et personligt tilbud fra dit prissystem
• Booking - Botten opretter en aftale i dit eksterne bookingsystem
• Rabatverificering - “Er denne rabatkode gyldig?” Botten tjekker og bekræfter
• Kontoopslag - En tilbagevendende kunde genkendes automatisk, og deres kontooplysninger hentes frem

Kunden ser aldrig, hvad der foregår bag kulisserne. De oplever blot en bot, der kan besvare deres spørgsmål med rigtig, opdateret information.

Hvordan brugerdefinerede funktioner fungerer (den enkle version) #

Her er hvad der sker, når en brugerdefineret funktion udløses under en samtale:

1. Kunden spørger om noget, der kræver realtidsdata (f.eks. “Hvor er min ordre?”)
2. Botten genkender, at den skal bruge en brugerdefineret funktion for at svare
3. Botten indsamler eventuel manglende information fra kunden (f.eks. “Hvad er dit ordrenummer?”)
4. Platformen sender en anmodning til dit system (din hjemmeside, CRM eller et andet værktøj) med de relevante detaljer
5. Dit system svarer med dataene (f.eks. ordrestatus, trackingnummer, leveringsdato)
6. Botten læser svaret og formulerer et naturligt svar: “Din ordre ORD-4582 er blevet afsendt og forventes at ankomme senest fredag!”

Hvad et brugerdefineret funktionskald koster #

Hvert brugerdefineret funktionskald faktureres baseret på din agents AI-kvalitetsniveau:

Opsætning af en brugerdefineret funktion (trin for trin) #

1. I hovedsidepanelet under AI Studio skal du klikke på Custom Functions.

2. Klik på den grønne + Add Function (eller New function) knap øverst til højre.

Listen over brugerdefinerede funktioner viser en tabel med følgende kolonner:

Dette gør det nemt at overskue dine funktioner og finde den, du skal bruge.

Trin 1: Giv den et navn og en beskrivelse #

Tip: Vær meget specifik i beskrivelsen og formålet. Jo tydeligere du er omkring, hvornår funktionen skal bruges, jo mere pålideligt vil botten bruge den på det rigtige tidspunkt.

Trin 2: Opsæt forbindelsen #

Du skal fortælle appen, hvor anmodningen skal sendes hen:

Hvilken metode skal man vælge:

Hvis du er i tvivl om, hvilken du skal bruge, så tjek med din udvikler eller dokumentationen for det system, du opretter forbindelse til. GET (til opslag) og POST (til oprettelse af poster) er de mest almindelige.

Trin 3: Tilføj godkendelsesoverskrifter (Authentication Headers) #

De fleste systemer kræver godkendelse for at acceptere anmodninger. Tilføj alle påkrævede overskrifter:

Værdier i headere, der indeholder en nøgle eller adgangskode, såsom Authorization eller X-API-Key, vises som prikker, når de er indtastet. Klik på øjet ved siden af værdien for at se den.

Sikkerhedstip: Brug en dedikeret API-nøgle med begrænsede tilladelser. Brug ikke legitimationsoplysninger på administratorniveau.

Hvor finder du API-nøgler: Tjek indstillingerne eller udviklersektionen i det system, du opretter forbindelse til (f.eks. dit CRM, din e-handelsplatform eller dit bookingsystem).

Trin 4: Definer input (Hvad botten sender) #

Inputparametre er de stykker information, som botten indsamler fra samtalen og sender til dit system.

For hver parameter angiver du:

Tilgængelige parametertyper:

Hver parameter har også et valgfrit felt til Sti for anmodningstekst (Request body path). Normalt sendes en parameter som et felt på øverste niveau i anmodningsteksten (eller som en forespørgselsstrengværdi for query_param-typen). Hvis dit slutpunkt forventer, at den er indlejret i stedet — f.eks. {"order": {"id": "ORD-123"}} — skal du indstille stien til order.id, så indlejrer platformen værdien der for dig.

Eksempel: Til et opslag af ordrestatus kan du definere:

• order_number (string, påkrævet): “Kundens ordrenummer. Starter normalt med ORD- efterfulgt af cifre. Spørg kunden om dette, hvis de ikke har nævnt det.”
• email (string, valgfri): “Kundens e-mailadresse til yderligere bekræftelse. Kun nødvendig, hvis ordrenummeret alene ikke finder et match.”

Hvad dit system modtager automatisk #

Udover de inputparametre, du definerer, inkluderer platformen automatisk systemdata med hver anmodning. Dit endpoint modtager dette i et system-felt:

Dette er nyttigt, hvis dit system har brug for at identificere kontakten, kontrollere hvilken agent der kaldte funktionen, eller opføre sig anderledes under test.

Når et opfølgende tjek kalder din funktion (se Send kun når et tjek består), er anmodningen anderledes end et kald i samtalen: den har ingen inputparametre, og feltet system indeholder kun system.contact (med dens id) plus en system.follow_up-blok (type, cycle_number, follow_up_number, reason, campaign_id, agent_id). Der er intet campaign-objekt i den. Spring systemdata over gælder også for det kald.

Har du ikke brug for systemdata? Slå Spring systemdata over-kontakten til i funktionsbyggeren. Botten sender derefter kun de inputparametre, du har defineret — ingen kontakt- eller agentdata. Brug dette, hvis dit endepunkt afviser uventede felter, eller hvis du blot ønsker en mindre payload.

Trin 5: Test det, og lad derefter botten læse svaret #

Du behøver normalt slet ikke at mappe svarfelter. Når dit slutpunkt svarer, læser botten hele JSON-svaret og bruger din funktions Beskrivelse og Formål (AI-handling) — plus hver parameters egen beskrivelse — til at finde ud af, hvad der er vigtigt, og præsentere det naturligt. En klar beskrivelse af selve funktionen (“Henter den aktuelle status for en kundeordre inklusive forsendelsesoplysninger og sporing”) gør mere af arbejdet her, end felt-for-felt-mapping ville gøre.

Hvis dit slutpunkt returnerer et stort svar, og du kun ønsker, at botten skal se et par specifikke værdier, skal du åbne sektionen Svar-mapping (som er skjult som standard, lige over Test). Hver række vælger ét felt på øverste niveau fra svaret: Svarfelt er feltnavnet i din API’s JSON-svar, og Outputfelt er det navn, botten modtager det under. Med mindst én udfyldt række modtager botten kun dine mappede værdier i stedet for hele svarteksten. Lad sektionen være tom for at bevare standardopførslen med fuldt svar.

Før du gemmer, skal du bruge Test-sektionen nederst i editoren til at sende anmodningen præcis som konfigureret og se det faktiske svar uden at forlade appen:

Det svar, du ser her, er slutpunktets rå svar. Hvis du har konfigureret Svarsmapping ovenfor, modtager botten i en rigtig chat kun de mappede felter — testen viser altid det fulde rå svar, så du kan se, hvad der er tilgængeligt at mappe. Hvis noget ser forkert ud (uventede feltnavne, ekstra indlejring), skal du rette det på dit slutpunkt eller justere din mapping.

Tildeling af funktioner til en agent #

Når du har oprettet en brugerdefineret funktion, skal du fortælle hver agent, hvilke funktioner den må bruge:

1. Åbn Agenten under AI Studio → AI-agenter.
2. Gå til fanen AI-evner.
3. Du vil se en liste over alle de brugerdefinerede funktioner, du har oprettet. Slå hver funktion til, som du ønsker, at denne agents bot skal kunne kalde.
4. Klik på Gem ændringer nederst. Valg træder først i kraft, når de er gemt.

Kun tildelte funktioner er tilgængelige for botten for den pågældende agent. Dette forhindrer botten i ved et uheld at bruge funktioner, der ikke er relevante.

Test af dine brugerdefinerede funktioner #

Før du går live, bør du teste grundigt:

1. Kør den indbyggede test - Brug Test-sektionen inde i funktionseditoren (se ovenfor) til et hurtigt tjek uden at forlade appen — udfyld realistiske værdier og klik på Kør test.
2. Test dit systems endpoint direkte - For den fulde tjekliste nedenfor graver et dedikeret værktøj som Postman (eller din udvikler) dybere end en enkelt Kør test.
3. Test i Prøv det - Simuler en samtale, hvor kunden spørger om noget, der bør udløse funktionen.
4. Tjek svaret - Sørg for, at botten korrekt læser og præsenterer dataene.
5. Test fejlscenarier - Hvad sker der, hvis kunden giver et ugyldigt ordrenummer? Hvad hvis dit system er midlertidigt nede?

Når testen returnerer 401 eller 403 #

En 401 eller 403 betyder, at dit endpoint modtog anmodningen og afviste den. Det afslørende tegn er, at intet dukker op i dine egne logfiler — de fleste værktøjer afviser et uautoriseret kald, før de overhovedet starter workflowet, så der er intet at se fra din side, og det ser ud som om, anmodningen aldrig ankom.

Dette skyldes næsten altid en uoverensstemmelse i godkendelsen: dit endpoint ønsker én type legitimationsoplysninger, og funktionen sender en anden. Kontroller, at den header, du tilføjede i Trin 3, er præcis den, dit system forventer.

Den mest almindelige version af dette er en webhook beskyttet med Basic Auth (n8n, Make og de fleste selvhostede værktøjer tilbyder dette som et afkrydsningsfelt på selve webhooken), mens funktionen sender en brugerdefineret hemmelig header som X-My-Secret. Basic Auth accepterer kun en Authorization-header, så en brugerdefineret header ignoreres, og kaldet afvises. Du har to muligheder:

• Slå Basic Auth fra på webhooken, og tjek i stedet din brugerdefinerede header inde i workflowet.
• Behold Basic Auth slået til, og tilføj en Authorization-header til funktionen, hvis værdi er ordet Basic efterfulgt af din base64-kodede username:password.

Begge dele virker — sørg blot for, at begge parter er enige.

Når testen returnerer 404 #

Endpoint-URL’en er forkert, eller workflowet er ikke publiceret. Specifikt i n8n har hver webhook en separat Test-URL og Production-URL, og test-URL’en lytter kun, mens du har editoren åben. Kopier Production-URL’en og sørg for, at workflowet er aktivt.

Se fejl i Try Out og Chats #

Når AI’en kalder en brugerdefineret funktion under en samtale, og kaldet fejler, for eksempel på grund af forkerte legitimationsoplysninger, et endpoint der er nede eller en timeout, viser samtalen det nu: en rød “(funktionsnavn) fejlede”-markør vises i tråden, både i agentens Test-fane og i rigtige samtaler i Chats. Klik på markøren for at udvide detaljerne: statuskoden dit endpoint returnerede og dens svartekst, hvilket normalt er nok til at fortælle dig præcis, hvad der skal rettes (en 401 med en “unauthorized”-besked betyder godkendelsesoverskriften, en timeout betyder at dit endpoint tog længere tid end 30 sekunder; for et job der kræver længere tid, se Langvarige jobs).

Succesfulde kald viser også en markør — klik på den for at se, hvad dit endpoint faktisk sendte tilbage. Dette er den hurtigste måde at debugge en integration fra ende til anden: hav testsamtalen i Try Out, og klik derefter på funktionsmarkøren for at se det faktiske resultat af anmodningen uden at forlade siden.

Når et værktøj bliver ved med at fejle i rigtige samtaler #

Hvis den samme brugerdefinerede funktion fejler 3 gange inden for 24 timer, mens din AI-agent chatter, får du én advarsel om dagen: via e-mail, under klokke-ikonet og som en push-besked, hvis du har aktiveret det. Advarslen navngiver værktøjet, viser den seneste fejl og linker til de berørte chats, da agenten vil have fortalt disse kontakter, at den stødte på et teknisk problem. Funktionens række i Indstillinger viser en Fejler-linje med fejloptællingen og den seneste fejl, indtil værktøjet virker igen; et enkelt vellykket kald nulstiller den. Du kan slå disse advarsler fra under Indstillinger → Notifikationer → Værktøjsfejl.

Komplet eksempel: Opslag af ordrestatus #

Her er et fuldt konfigureret eksempel, som du kan bruge som skabelon:

Grundlæggende oplysninger:

• Navn: check_order_status
• Beskrivelse: “Henter den aktuelle status for en kundeordre, inklusive forsendelsesoplysninger og sporing”
• AI-handling: “Kald denne, når en kunde spørger om deres ordrestatus, hvor deres pakke er, eller hvornår den ankommer. Bed altid om ordrenummeret først.”

Forbindelse:

• URL: https://api.mystore.com/orders/lookup
• Metode: POST

Headere:

• Authorization: Bearer sk_live_abc123
• Content-Type: application/json

Inputparametre:

• order_number (tekst, påkrævet): “Ordrenummeret oplyst af kunden”
• customer_email (tekst, valgfri): “Kundens e-mail til yderligere bekræftelse”

Ingen svar-mapping nødvendig — med en klar beskrivelse og AI-handling allerede indstillet ovenfor, læser botten den JSON, dit endpoint returnerer (status, sporingsnummer, leveringsdato, varer), og finder ud af, hvordan den skal tale om det.

Hvordan samtalen ser ud:

Kunde: Hej, hvor er min ordre?

Bot: Hej! Jeg vil meget gerne tjekke din ordre. Kan du dele dit ordrenummer med mig?

Kunde: Det er ORD-78234

Bot: Lad mig slå det op for dig…

Din ordre ORD-78234 er blevet afsendt og er på vej! Den forventede leveringsdato er 10. marts. Du kan spore din pakke her: https://tracking.example.com/1Z999AA1

Er der andet, jeg kan hjælpe dig med?

Komplet eksempel: Shopify-ordrestatus #

Hvis butikken kører på Shopify, behøver du ikke en udvikler til at bygge et opslagsslutpunkt — Shopifys eget system kan besvare ordrespørgsmål direkte. (For spørgsmål om produkter og lager i en Shopify-butik behøver du slet ikke en tilpasset funktion: forbind i stedet butikkens indbyggede server — se Forbind en Shopify-butik.)

Opret først et adgangstoken i Shopify. Shopify ændrede dette i løbet af 2026: apps kan ikke længere oprettes inde i Shopify-administratoren, og den nye app-skærm giver dig et Client ID og en Client secret i stedet for et færdigt token. Trinene nedenfor omdanner disse til et permanent token. Sæt ti minutter af til det, én gang pr. butik. (Hvis butikken allerede har en ældre app oprettet på den gamle måde, vil dens eksisterende token fortsat fungere – spring direkte til den brugerdefinerede funktion nedenfor.)

1. Gå til Shopify Dev Dashboard på dev.shopify.com, åbn din organisation, og klik på Apps → Create app. Giv den et navn som f.eks. Order lookup.
2. Giv appen tilladelsen read_orders, udgiv en version, og installer appen i butikken.
3. Åbn appens Settings og tilføj butikkens egen webadresse (f.eks. https://www.yourstore.com/) til de tilladte omdirigerings-URL’er (redirect URLs). Gem.
4. Stadig under Settings, kopier Client ID og Client secret.
5. I en browser, hvor du er logget ind på den pågældende butiks Shopify-admin, skal du åbne adressen nedenfor og erstatte butiksnavnet, klient-ID’et og omdirigeringsadressen med dine egne: https://YOUR-STORE.myshopify.com/admin/oauth/authorize?client_id=YOUR-CLIENT-ID&scope=read_orders&redirect_uri=https://www.yourstore.com/&state=12345 Godkend skærmen, der vises. Browseren lander på din omdirigeringsadresse, og adresselinjen indeholder nu code= efterfulgt af en lang værdi — kopier denne værdi. Den er kun gyldig i et par minutter, så gå direkte til næste trin.
6. Ombyt denne kode med tokenet, hvilket du kan gøre inde i Your AI Connector. I editoren til brugerdefinerede funktioner skal du indstille Method til POST og URL til https://YOUR-STORE.myshopify.com/admin/oauth/access_token, tilføje tre tekst-inputparametre navngivet client_id, client_secret og code, klik derefter på Test, udfyld de tre værdier, og kør den. Svaret indeholder access_token — det er dit permanente token. Kopier det et sikkert sted hen, ryd derefter editoren og opsæt den rigtige funktion nedenfor.

Opsæt derefter den tilpassede funktion:

Grundlæggende oplysninger:

• Navn: check_shopify_order
• Beskrivelse: “Slår en ordre op i butikkens Shopify-system og returnerer dens status, sporing og varer”
• AI-handling: “Kald denne, når en kunde spørger om deres ordrestatus eller levering. Bed altid om ordrenummeret først.”

Forbindelse:

• URL: https://YOUR-STORE.myshopify.com/admin/api/2026-01/orders.json?status=any — erstat YOUR-STORE med butikkens .myshopify.com-navn (denne adresse bruger det tekniske Shopify-domæne, ikke butikkens brugerdefinerede domæne)
• Metode: GET

Headere:

• X-Shopify-Access-Token: shpat_... (tokenet fra før)

Inputparametre:

• name (query_param, påkrævet): “Kundens ordrenummer præcis som det fremgår af deres ordrebekræftelse, inklusive #-tegnet — for eksempel #1001. Bed kunden om det, hvis de ikke har nævnt det.”

Ingen svar-mapping nødvendig — botten læser den returnerede ordre (betalingsstatus, leveringsstatus, sporing, varer) og svarer naturligt.

Godt at vide: et token oprettet på denne måde kan se ordrer fra de sidste 60 dage — rigeligt til daglige supportspørgsmål, men ikke en fuld ordrehistorik.

Komplet eksempel: Book en aftale #

Grundlæggende oplysninger:

• Navn: create_booking
• Beskrivelse: “Opretter en ny aftale i vores bookingsystem”
• AI-handling: “Brug denne efter at have bekræftet dato, tid og kontaktoplysninger med kunden. Kald den ikke, før kunden eksplicit bekræfter, at de ønsker at booke.”

Forbindelse:

• URL: https://booking.mycompany.com/api/appointments
• Metode: POST

Inputparametre:

• date (tekst, påkrævet): “Aftaledato i formatet ÅÅÅÅ-MM-DD”
• time (tekst, påkrævet): “Aftaletidspunkt i formatet TT:MM”
• name (tekst, påkrævet): “Kundens fulde navn”
• phone (tekst, påkrævet): “Kundens telefonnummer”
• service_type (tekst, påkrævet): “Typen af service, der bookes”

Komplet eksempel: Tilføj en nyhedsbrevsabonnent til dit CRM #

Et meget almindeligt mønster: botten er færdig med at svare, tilbyder dit nyhedsbrev, kontakten svarer med sin e-mailadresse, og den adresse skal lande direkte i dit e-mailværktøj. De fleste CRM-systemer (FluentCRM, ActiveCampaign, MailerLite, Brevo og andre) accepterer et simpelt POST-kald til netop dette, så der er ikke brug for en automatiseringsplatform imellem.

Dette eksempel bruger FluentCRM på WordPress. Strukturen er den samme for ethvert andet værktøj, der giver dig et “indgående webhook” eller et “opret abonnent”-endepunkt.

Først skal du hente URL’en fra dit CRM. I WordPress skal du åbne FluentCRM → Indstillinger → Indgående webhooks og oprette et webhook. Vælg den liste, de tags og den abonnementsstatus, som nye kontakter skal have, og kopiér derefter den webhook-URL, der genereres. Alt, hvad du indstiller her, anvendes automatisk, så botten skal kun sende e-mailadressen.

Opsæt derefter den tilpassede funktion:

Grundlæggende oplysninger:

• Navn: add_newsletter_subscriber
• Beskrivelse: “Tilføjer en person til vores nyhedsbrevsliste ved hjælp af den e-mailadresse, de opgav i chatten”
• AI-handling: “Brug denne i det øjeblik, kontakten accepterer at abonnere på nyhedsbrevet og opgiver sin e-mailadresse. Kald den ikke, før de rent faktisk har opgivet en adresse, og kald den ikke to gange for den samme person.”

Forbindelse:

• URL: den webhook-URL, du kopierede fra dit CRM
• Metode: POST

Inputparametre:

• email (streng, påkrævet): “Den e-mailadresse, som kontakten opgav i samtalen”
• first_name (streng, valgfri): “Kontaktens fornavn, hvis de har nævnt det”

Spring systemdata over: slå denne til. Dit CRM har kun brug for felterne ovenfor, og en mindre nyttelast undgår fejl fra værktøjer, der afviser uventede felter.

Svarsmapping: ikke nødvendig her. Der behøver ikke komme noget retur, for at botten kan fortsætte.

Glem ikke at aktivere funktionen for den Agent, der kører samtalen (se Tildeling af funktioner til en agent). Dette er den mest almindelige årsag til, at en korrekt bygget funktion aldrig aktiveres.

Tips til pålidelige brugerdefinerede funktioner #

1. Sørg for, at gentagne anmodninger er sikre. Hvis den samme anmodning ved et uheld sendes to gange, bør den ikke oprette dublerede poster. Netværksproblemer kan lejlighedsvis forårsage dette.

2. Returnér klare fejlmeddelelser. Hvis noget går galt på dit systems side, skal du returnere en menneskeligt læsbar fejl. Botten vil videreformidle den til kunden på en elegant måde.

3. Hold svartiderne under 10 sekunder. Hvis dit system tager længere tid, bør du overveje først at returnere en hurtig bekræftelse.

4. Håndter udløbne eller ugyldige legitimationsoplysninger. Hvis din API-nøgle udløber, skal du sørge for, at fejlmeddelelsen er klar, så botten ved, at den skal give besked til et menneske i stedet for at prøve igen.

5. Skriv detaljerede beskrivelser. AI’en bruger dine beskrivelser til at finde ud af, hvornår funktionen skal kaldes, og hvordan den rette information skal udtrækkes fra samtalen. Vage beskrivelser fører til fejl.

6. Test med rigtige samtaler. Try Out er fantastisk til indledende test, men overvåg dine første par live-samtaler for at sikre, at alt fungerer med rigtige kundehenvendelser.

7. Hold logfiler på din side. Bed din udvikler om at logge de anmodninger, der kommer fra appen, så du hurtigt kan fejlfinde eventuelle problemer.

8. Hvis din firewall har brug for en IP-tilladelsesliste, sendes hvert kald til en brugerdefineret funktion (og hvert opfølgende tjek) fra én fast IPv4-adresse, den samme som vores webhooks bruger; ingen intervaller, ingen IPv6, ingen rotation. Kontakt support, så giver vi dig adressen. Slå anmodningssignering til og tjek signaturen som din reelle tillidskontrol, og betragt IP-adressen som et ekstra filter.

9. Brug en offentlig endelig URL. Din funktions-URL skal være en offentlig webadresse (HTTP/HTTPS). Interne adresser, localhost og adresser på private netværk afvises af sikkerhedshensyn, og platformen følger ikke omdirigeringer — peg funktionen direkte mod den endelige URL, ikke mod en, der omdirigerer til den.

Langvarige jobs: få resultatet senere #

Normalt skal en brugerdefineret funktion svare inden for 30 sekunder, mens kontakten venter på svaret. Nogle jobs tager længere tid end det: at rendere en video, køre et kreditcheck, vente på at en person hos dig godkender noget. Til disse skal du slå Resultatet kommer senere (langvarig) til. AI’ens kald starter derefter kun jobbet. Din tjeneste svarer med det samme, AI’en fortæller kontakten, at resultatet er på vej og fortsætter samtalen, og din tjeneste sender resultatet til et callback-link, når det er færdigt.

Hvornår skal det bruges #

Brug det, når din tjeneste ikke pålideligt kan svare inden for 30 sekunder. Lad det være slået fra for hurtige opslag (en ordrestatus, et lagertjek, en pris): disse er enklere som et normalt kald, fordi AI’en svarer med resultatet i det samme svar.

Indstillingerne i editoren #

Du finder disse i editoren for brugerdefinerede funktioner, ved siden af Spring systemdata over.

Hvad din tjeneste modtager #

Med kontakten slået til, bærer hvert kald callback-linket tre steder, udover alt det ovenfor beskrevne (dine inputparametre, system-blokken og signerings-headere):

Linket er unikt for hvert kald, tilhører den kontakt og det kald, virker én gang og udløber efter Vent op til. Du behøver ikke en API-nøgle for at bruge det: selve linket er tilladelsen. Behandl det som en adgangskode og skriv det aldrig i en offentlig log.

Afsendelse af resultatet #

Når jobbet er færdigt, send en POST til callback-linket:

POST https://api.<your host>/v1/custom-functions/callback/d3f9...
Content-Type: application/json

{
  "result": { "video_url": "https://cdn.example.com/spring-offer.mp4", "duration_seconds": 42 },
  "message": "Your video is ready: https://cdn.example.com/spring-offer.mp4"
}

• result er det, som AI’en læser. Det kan være tekst eller et JSON-objekt.
• message er valgfrit. Med Send teksten som den er, modtager kontakten message, når du sender en, ellers result, når det er tekst.
• media_url er valgfrit: et https link til en fil (billede, video, lyd eller dokument), som kontakten modtager som en rigtig vedhæftet fil, ikke som et link. Se Afsendelse af en fil nedenfor.
• Du kan også sende en brødtekst med almindelig tekst med Content-Type: text/plain. Den behandles som result.
• Brødteksten kan være på op til 64 KB.

Hvad callback-linket svarer:

Et komplet eksempel: en video, der tager tre minutter #

1. AI’en kalder din funktion. Du modtager (forkortet):

POST https://api.example.com/render
X-Callback-Url: https://api.<your host>/v1/custom-functions/callback/d3f9...
Content-Type: application/json

{
  "video_title": "Spring offer",
  "callback_url": "https://api.<your host>/v1/custom-functions/callback/d3f9...",
  "system": {
    "contactId": "...",
    "callback_url": "https://api.<your host>/v1/custom-functions/callback/d3f9...",
    "callback_expires_at": "2026-10-20T19:15:00.000Z"
  }
}

2. Din tjeneste starter renderingen og svarer med det samme:

{ "status": "started" }

3. AI’en fortæller kontakten, at videoen bliver lavet, og fortsætter chatten.
4. Tre minutter senere poster din tjeneste resultatet til callback-linket:

{ "result": { "video_url": "https://cdn.example.com/spring-offer.mp4", "duration_seconds": 42 } }

5. AI’en skriver den næste besked med sine egne ord, for eksempel “Din video er klar: https://cdn.example.com/spring-offer.mp4”.

Bruger du Zapier eller Make? Lad trigger-webhooken modtage kaldet, og gør det sidste trin i flowet til et POST til callback_url fra trigger-dataene.

Hvad der sker i chatten #

Resultatet gemmes i samtalen som en funktionspost, så du ser det i indbakken ligesom ethvert andet brugerdefineret funktionskald. Derefter, afhængigt af Når resultatet ankommer, skriver og sender AI’en den næste besked (dette koster ét AI-svar, ligesom enhver AI-besked), eller din tekst sendes, som den er. Med Send teksten som den er, sendes message-feltet, når du inkluderer et, ellers result, når det er almindelig tekst; hvis du kun poster et objekt uden tekst, skriver AI’en beskeden i stedet.

Hvis AI’en er slået fra for den kontakt, når resultatet ankommer (et teammedlem har overtaget, AI’en var sat på pause, agenten er slukket eller løbet tør for kreditter), gemmes resultatet stadig i samtalen, men der sendes ingen besked. Den sendes heller ikke senere, når AI’en tændes igen. Teammedlemmet ser resultatet i chatten og kan bruge det.

I agentens Prøv-fane fungerer hele flowet også: resultatet ankommer i testchatten.

Afsendelse af en fil (video, billede, PDF) #

Et resultat, der er en fil, for eksempel en video, som din tjeneste har gengivet i baggrunden, når frem til kontakten som en vedhæftet fil, som de kan åbne i chatten, i begge tilstande. Platformen finder filen i dit callback på denne måde:

1. media_url i brødteksten, når du sender en.
2. Ellers et filfelt på result-objektet: file_url, video_url, image_url, pdf_url, document_url, audio_url, attachment_url eller download_url.
3. Ellers det første https link i teksten, der slutter med en filendelse såsom .mp4, .jpg, .png eller .pdf.

Med AI’en skriver den næste besked, skriver AI’en teksten, og filen vedhæftes den besked (AI’en får besked på ikke at indsætte linket). Med Send teksten som den er, er din message billedteksten til den vedhæftede fil.

{
  "result": { "status": "done", "title": "Spring offer" },
  "message": "Your video is ready.",
  "media_url": "https://cdn.example.com/spring-offer.mp4"
}

Filer kan være på op til 16 MB og skal kunne tilgås via https. Hver kanal understøtter forskellige typer: for eksempel understøtter e-mail- og WhatsApp-kanaler video, billeder, lyd og dokumenter, mens SMS ikke understøtter filer. Når en kanal ikke kan modtage filen, eller filen er for stor, modtager kontakten stadig beskeden med linket til filen tilføjet til sidst.

Når resultatet aldrig ankommer #

Hvis intet postes, før Vent op til løber ud, får AI’en besked om, at resultatet aldrig kom, så den kan give kontakten besked. En post med koden APP-3103 vises under Indstillinger → Fejllog, og du modtager en værktøjsfejlmeddelelse.

Grænser i korte træk #

• Ét resultat pr. callback-link. Senere opslag til det samme link besvares som dubletter og ændrer intet.
• Op til 64 KB pr. resultat.
• Én fil pr. resultat, op til 16 MB, via https.
• Op til 20 opslag i minuttet til ét link.
• Vent op til fra 1 til 168 timer.
• Din tjeneste har stadig 30 sekunder til at besvare det første kald.

Verificering af, at et kald rent faktisk kom fra os #

Enhver, der finder din funktions URL, kan sende den en falsk anmodning. En lang hemmelighed i en godkendelsesoverskrift hjælper, men det er den samme værdi ved hvert kald, så enhver, der ser én anmodning (i en log eller et skærmbillede), kan genbruge den. Anmodningssignering løser dette: hvert kald bærer en signatur, som kun en person, der besidder din hemmelighed, kan producere, og som udløber efter et par minutter.

Signering er valgfri og slået fra som standard, og det er én indstilling for hele din konto: en enkelt hemmelighed signerer hver brugerdefineret funktion.

Aktivering af signering #

1. Åbn Brugerdefinerede funktioner.
2. Under din liste over funktioner skal du finde kortet Anmodningssignering og klikke på Slå signering til.
3. Klik på Vis, kopiér hemmeligheden (den starter med whsec_) og gem den i det system, der modtager kaldene. Behandl den som en adgangskode.

Fra det samme kort kan du kopiere hemmeligheden igen, Rotere den (den gamle holder op med at virke med det samme) eller Slå signering fra.

Hvad vi sender #

Når signering er slået til, bærer hvert kald, som en brugerdefineret funktion foretager, to ekstra overskrifter: AI’ens kald under en chat, betingelser for afsendelse af opfølgning og knappen Kør test i editoren.

Hvert kald, uanset om det er signeret eller ej, bærer også User-Agent: Custom-Function/1.0, medmindre du angiver din egen User-Agent-overskrift.

Overskrifterne og signaturen fungerer præcis som signerede webhooks, så hvis du allerede verificerer vores webhooks, virker den samme kode her. Kun hemmeligheden er anderledes.

Sådan verificerer du #

Signaturen er en HMAC-SHA256 af strengen <timestamp>.<raw request body>, hvor din signeringshemmelighed bruges som nøgle. Tjek den mod den rå brødtekst, de præcise bytes du modtog: parsing af JSON og konvertering tilbage til tekst kan ændre bytes, og signaturen vil ikke matche.

En funktion, der bruger GET (eller en POST uden noget at sende), har ingen brødtekst, så den signerede streng er blot <timestamp>. med en tom brødtekst. Signaturen beviser derefter, at kaldet kom fra os og er nyligt, men den dækker ikke forespørgselsstrengen.

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");
  const received = signature.replace("v1=", "");

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

Python-eksempel:

import hashlib, hmac, time

def verify(raw_body: bytes, headers, secret: str) -> bool:
    timestamp = headers.get("X-Webhook-Timestamp", "")
    signature = headers.get("X-Webhook-Signature", "").replace("v1=", "")
    if not timestamp or 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)

Test det med Kør test i editoren: når signering er slået til, bliver testkaldet signeret præcis som et live-kald, så en funktion, der består testen, vil også bestå dit tjek under rigtige chats.

Bruger du API’et? Den samme hemmelighed kan læses, genereres eller roteres og fjernes med GET, POST og DELETE på /v1/custom-functions/signing-secret.

Udførelsesgrænser #

Hver brugerdefineret funktion har et valgfrit afsnit om Udførelsesgrænser nederst i editoren. Det styrer, hvor ofte AI’en må køre funktionen, og om et tidligere resultat kan genbruges. Alt her er valgfrit — lad det hele stå tomt, så opfører funktionen sig præcis som før.

Skrivebeskyttet funktion. Slå dette til, hvis din funktion kun læser data — et opslag af lagerbeholdning, et pristjek, en søgning efter ordrestatus — og aldrig opretter eller ændrer noget. Når et midlertidigt netværksproblem afbryder AI’en midt i et svar, kan platformen sikkert forsøge samtalen igen i stedet for at efterlade kunden uden et svar. Aktivér den kun, hvis funktionen virkelig aldrig skriver noget: en funktion, der opretter poster, skal forblive slået fra, så et nyt forsøg aldrig ved et uheld kan køre den to gange. Funktioner, der bruger GET-metoden, behandles automatisk som skrivebeskyttede, da GET-anmodninger kun er beregnet til at hente data; POST-, PUT-, PATCH- og DELETE-funktioner kræver denne indstilling.

Brug cachelagret resultat ved gentagne kald. Når AI’en kalder funktionen igen med de samme input (for eksempel hvis kunden stiller det samme spørgsmål to gange), genbruges det forrige resultat i stedet for at kalde dit endepunkt igen. Cachelagrede resultater gemmes i op til 24 timer, og et kald med forskellige input går altid direkte til dit endepunkt.

Maks. kørsler pr. samtale. En fast grænse for, hvor mange gange funktionen må køre inden for én samtale. Sæt den til 1 for funktioner, der kun bør køre én gang pr. chat — generering af et tilbud, udløsning af et tilbagekald, start af en automatisering. Når grænsen er nået, får AI’en besked om, at funktionen allerede er kørt, og får det seneste resultat, så den stadig kan svare kunden i stedet for at forblive tavs.

Maks. kørsler pr. tidsvindue. En hastighedsbegrænsning over tid: for eksempel højst 5 kørsler inden for 60 minutter. Nyttigt for funktioner, der kalder betalte tredjepartstjenester eller udløser tungere automatiseringer. Begge felter skal udfyldes sammen (et antal kørsler og et vindue i minutter, op til 7 dage).

Afsendelse af tilbud, kontrakter eller fakturaer på LinkedIn. Når AI’en svarer på LinkedIn, skriver den fra kontoejerens egen indbakke, så den bør ikke sende et tilbud, en kontrakt, et prisoverslag, en faktura, et betalingslink eller give adgang på ejerens vegne, medmindre ejeren har givet tilladelse til det. Med Automatisk (standardindstillingen) køres en funktion, hvis navn eller beskrivelse indikerer, at den sender en af disse ting, ikke på LinkedIn: AI’en får besked om, at intet blev sendt, og informerer personen om, at ejeren vil tage sig af det. Vælg Tilladt for alligevel at lade funktionen køre på LinkedIn, eller Aldrig på LinkedIn for at blokere en funktion, som den automatiske kontrol ville overse. Andre kanaler påvirkes ikke, og i modsætning til begrænsningerne ovenfor gælder denne indstilling også i Prøv det-funktionen.

Et par ting, du bør vide:

• Grænser tæller kun succesfulde kørsler. Et kald, der fejlede på dit endepunkts side, bruger ikke af budgettet.
• Når en kørsel blokeres af en grænse, bliver kunden aldrig ladt i stikken — AI’en får besked om hvorfor og arbejder videre med den information, den allerede har.
• Grænser gælder overalt, hvor funktionen kører: almindelige chats på alle kanaler og funktioner styret af en automatisering. Test-samtaler i “Prøv” tælles ikke med og er ikke begrænsede.

Indbyggede bot-værktøjer #

Ud over de brugerdefinerede funktioner, du selv bygger, leveres platformen med et bibliotek af præbyggede værktøjer, som AI-botten kan bruge under en samtale. Disse dækker de mest almindelige opgaver, en bot skal udføre — at give besked til en kollega, booke en aftale, tilføje et tag til en kontakt, søge på din hjemmeside, planlægge en opfølgning og meget mere — så du ikke behøver at bygge dem fra bunden.

Botten beslutter, hvornår hvert værktøj skal bruges, baseret på hvad der sker i samtalen, og hvordan din agent er konfigureret. De fleste af disse værktøjer aktiveres automatisk, når den relaterede funktion er slået til (for eksempel bliver bookingværktøjerne kun tilgængelige, når du forbinder en kalender og aktiverer bookinger).

Credit-omkostning: Hvert værktøjskald faktureres baseret på din agents AI-kvalitetsniveau, og brugerdefinerede funktioner, som du selv bygger, faktureres på samme måde:

Team- og opgaveværktøjer #

Kontaktværktøjer #

Værktøjer til aftaler og booking #

Disse værktøjer er kun tilgængelige, når bookinger er aktiveret på din agent, og en kalenderbegivenhedstype er konfigureret.

Videns- og webværktøjer #

Opfølgningsværktøjer #

Disse værktøjer kræver, at opfølgninger er aktiveret på din agent.

Kører til brugerdefinerede funktioner #

Værktøjer til restaurantbooking (Zenchef og Formitable) #

Disse værktøjer er kun tilgængelige, når en Zenchef- eller Formitable-integration er tilsluttet. De lader botten administrere restaurantreservationer fra start til slut.

Aktivering og deaktivering af værktøjer #

De fleste værktøjer styres på agentens fane AI-evner:

• Bookingværktøjer aktiveres, når du aktiverer bookinger og forbinder en kalender i Bookings-kortet på den samme fane AI-evner
• Opfølgningsværktøjer aktiveres, når du aktiverer opfølgninger
• Restaurantværktøjer aktiveres, når du forbinder en Zenchef- eller Formitable-konto
• Websøgning har sin egen kontakt på fanen FAQ & Viden
• Opgaveværktøjer kan slås fra pr. agent med kontakten Tillad AI at oprette opgaver (de er slået til som standard; den kontoomfattende opgavekontakt i Indstillinger → Profil → Funktioner slår hele opgavesystemet fra overalt)
• Kontakt-opdateringsværktøjer styres på den samme fane AI-evner — uanset om AI’en må omdøbe kontakter eller gemme ekstra indsamlet information på dem
• Alarmværktøjer er altid tilgængelige; tagging kører automatisk efter hvert botsvar (det er ikke et værktøj, botten vælger at kalde)

Hvis du vil have botten til at stoppe med at bruge et specifikt indbygget værktøj, er den reneste måde at deaktivere den underliggende funktion (deaktiver f.eks. bookinger for at slå alle bookingværktøjer fra).

Funktioner administreret af en automatisering #

Nogle poster på din side for tilpassede funktioner kan have et Administreret af automatisering-badge. Disse er ikke oprettet her — de kommer fra en automatisering med en AI Agent-funktion-udløser, som giver din agent en evne, hvis trin du opbygger visuelt på automatiseringslærredet i stedet for at pege på en ekstern webadresse.

En administreret funktion passes for dig: dens navn, beskrivelse og felter følger altid det, der er indstillet på automatiseringens trigger, så den kan ikke redigeres eller slettes fra denne side — brug dens Åbn automatisering-link og skift selve automatiseringen. Du kan dog stadig vælge, hvilke agenter der skal have den på normal vis: på en agents AI-evner-fane vises den sammen med agentens andre evner med en almindelig til/fra-knap (hvis dens automatisering er sat på pause, angiver rækken dette — evnen bliver aktiv, når automatiseringen tændes). Alt andet ved den fungerer ligesom enhver anden brugerdefineret funktion: AI’en beslutter, hvornår den skal kaldes, indsamler de detaljer, du har defineret, og kan bruge automatiseringens svar i den samme samtale.

Hvis du skal vælge mellem de to: peg en almindelig brugerdefineret funktion mod et system, der allerede har en adresse, der kan kaldes; byg en automatisering med en AI Agent Function-udløser, når arbejdet er noget, du hellere vil samle af trin — slå noget op i et regneark eller en database, forgrene baseret på en betingelse, oprette poster — uden at køre din egen server. Se Automatiseringer.

Plan-krav #

Brugerdefinerede funktioner er tilgængelige på planer, der inkluderer funktionen for brugerdefinerede funktioner. Tjek dit abonnement for at bekræfte tilgængelighed.

Næste skridt #

• Forbind MCP-servere til din bot — en færdig pakke af værktøjer i stedet for én funktion ad gangen.
• AI-agenter — hovedsiden for den AI Studio-gruppe, som brugerdefinerede funktioner hører til, og hvor brugerdefinerede funktioner tildeles en bot.