formbasedocs
Gå til appenAppen

Integrasjoner

Webhooks

Send hver innsending som en signert POST-forespørsel til en hvilken som helst URL — ditt backend, automatiseringsplattform eller serverløs funksjon.


Slik fungerer det

Ved hver innsending sender formbase en JSON-kropp som POST til webhook-URL-en din. Forespørselen signeres med HMAC-SHA256, prøves på nytt ved feil og logges i integrasjonens hendelseslogg. Denne siden dekker oppsettet. Den nøyaktige nyttelasten, hodene og signaturalgoritmen finner du i webhook-referansen.

Legg til en webhook

  1. 1

    Åpne skjemaets integrasjoner

    Skjema → Innstillinger → Integrasjoner → Webhook.

  2. 2

    URL

    Skriv inn vert og sti — https://-prefikset er fast i feltet. Vanlig http:// godtas bare for localhost under utvikling.

  3. 3

    Tilordning

    La den stå tom for å sende hvert felt. Legg til rader for å sende bare de feltene, under JSON-nøkkelen du velger. Tilordningen former answers og display samtidig, så en nøkkel du gir nytt navn, får det nye navnet i begge. Hele forespørselen under tilordningen tegnes på nytt etter hvert som du redigerer den.

  4. 4

    Hoder

    En signeringshemmelighet som starter med whsec_ genereres for deg. Den kan ikke endres etter opprettelse. I samme trinn legger du til opptil 5 egendefinerte hoder endepunktet ditt trenger, for eksempel et autorisasjonstoken, og slå på Send feltlisten med hver hendelse hvis mottakeren din ikke kan kalle fields.list. Content-Type settes automatisk og kan ikke overstyres.

  5. 5

    Fullfør

    Trykk Send en testhendelse for å POST-e et syntetisert eksempelsvar, og trykk deretter Opprett integrasjon.

Flere webhooks

Du kan knytte flere webhooks til ett enkelt skjema. Hver utløses uavhengig for hvert arrangement.

Hvilke URL-er formbase godtar

  • https:// overalt, eller http:// for localhost og *.localhost under utvikling.

  • Ingen påloggingsinformasjon i URL-en, og maks 2 048 tegn.
  • Ingen private eller interne adresser. Vertsnavnet slås opp og sjekkes på nytt rett før hver levering, så en DNS-post som senere peker til en intern adresse, blir fortsatt avvist.

En avvist URL er et konfigurasjonsproblem, ikke et forbigående: leveringen mislykkes permanent i stedet for å prøves på nytt.

Hva du mottar

Hver forespørsel er den samme hendelseskonvolutten — id, type, createdAt, apiVersion, test og data. Inne i data ligger skjemaet, innsendingen (id, respondentens e-post, innsendingstidspunkt, PDF-lenke, språk), et answers-objekt nøkkelsatt med feltnøkkel, og et display-objekt med de samme nøklene som lesbar tekst. Hvert svar står én gang, i hvert kart.

Se referansen for hele nyttelastformatet, answers og display, og hvordan en gjentakende gruppe representeres.

For å forhåndsvise den nøyaktige kroppen for skjemaet ditt, åpne integrasjonen og utvid Eksempel på nyttelast under signeringshemmeligheten. Den gjengir din nåværende tilordning med eksempelsvar.

Verifisering av signaturer

Hver forespørsel inneholder et X-formbase-Signature-hode: t=TIMESTAMP,sha256=HEX, en HMAC-SHA256 av TIMESTAMP.BODY beregnet med signeringshemmeligheten din. Selve hemmeligheten sendes aldri. Referansen har et kopier-og-lim-inn-verifiseringsutdrag.

Hendelser for avbrutte svar

Egendefinerte webhooks utløses bare for fullførte innsendinger og redigeringer — aldri for avbrutte utkast. En egendefinert webhook er den eneste mottakeren som får begge deler: et Zapier-, Make- eller n8n-abonnement velger første innsendinger eller redigeringer, aldri begge. For avbrutte utkast, bruk en leverandør som har et Forlatte innsendinger-trinn: Google Sheets, Airtable, Notion, Slack, Discord, Linear eller GitHub Issues. Hver har sitt eget inaktivitetsvindu og, der det gjelder, sin egen meldingsmal. Dette trinnet krever Pro eller Business.

Nye forsøk og feil

  • En levering lykkes ved enhver 2xx.

  • Opptil 5 forsøk: det første sendes umiddelbart, nye forsøk venter minst 1, 2, 4 og 8 minutter. formbase ser etter forfalte nye forsøk hvert 30. minutt, så det siste forsøket kommer om lag to timer etter det første. Et Retry-After-hode på en 429 eller 5xx respekteres når det ber om lengre ventetid.

  • 429, 5xx, tidsavbrudd og tilkoblingsfeil prøves på nytt. Alle andre 4xx-feil mislykkes umiddelbart.

  • Etter 5 påfølgende feil settes integrasjonen automatisk på pause, og personen som satte den opp får en e-post. Fiks endepunktet, og trykk deretter Gjenoppta.

  • 401, 403 og 404 stopper integrasjonen umiddelbart med en feilstatus og samme e-post — det er ingen venting på fem feil.

  • Leveringer som har brukt opp alle 5 forsøkene, samles i et banner på integrasjonen. Prøv alle på nytt setter dem i kø igjen og reaktiverer en pauset integrasjon.

Testing

Send en testhendelse vises på Fullfør-trinnet og igjen på den lagrede integrasjonen. Den POST-er et syntetisert eksempelsvar — «John Doe» for tekst, 42 for tall, john@example.com for e-post — signert og med dine egendefinerte hoder, akkurat som en ekte levering. Fra den lagrede integrasjonen skriver den også en tilkoblingstest-oppføring til hendelsesloggen.

For lokal utvikling, eksponér dev-serveren din med en tunnel:

bash
# ngrok
ngrok http 3000

# cloudflare tunnel

cloudflared tunnel --url http://localhost:3000

FAQ

Ja. Hver har sin egen URL, signeringshemmelighet og egendefinerte hoder. Alle aktive webhooks utløses uavhengig for hver innsending.

Ja. Legg til hoder endepunktet ditt trenger (f.eks. Authorization: Bearer …) under oppsett. Du kan ikke overstyre Content-Type.

Nei. Signeringshemmeligheten genereres én gang når webhook-en opprettes og kan ikke endres. Hvis du trenger en ny hemmelighet, sletter du webhook-en og oppretter en ny.

Ja. Åpne integrasjonen, rediger URL-en, og lagre. Signeringshemmeligheten og hendelseshistorikken følger med.

Kun for localhost og *.localhost under utvikling. Alle andre URL-er må bruke HTTPS.

Slett den fra Skjemainnstillinger → Integrasjoner. formbase slutter å sende forespørsler umiddelbart, og integrasjonens hendelseshistorikk slettes sammen med den.

Neste steg