Webhooks

Oversikt⁠

POST /api/v1/webhooks abonnerer en URL på hendelser, og DELETE /api/v1/webhooks/{id} fjerner webhooken igjen. De er abonner- og avslutt-kallene i en REST hook, som er måten en Zapier-trigger lytter etter hendelser på. GET /api/v1/webhooks/samples/{event} gir eksempelhendelser til testtrinnet i en trigger, og GET /api/v1/webhooks og GET /api/v1/webhooks/{id} leser webhookene dere har.

Alle de fem kallene trenger tillatelsen Admin, og medlemmet som eier nøkkelen, må være administrator i arbeidsområdet når forespørselen kjører. En nøkkel der medlemmet ikke lenger er administrator, får insufficient-scope fra da av. Webhooks følger med API-et, på Business og Enterprise.

En webhook du oppretter her, er den samme som en administrator setter opp under Innstillinger → API. Den vises der, den handler som medlemmet som eier nøkkelen, og den følger reglene for forespørsel, signatur og nye forsøk i Kom i gang.

Abonner⁠

curl -X POST "https://attia.app/api/v1/webhooks" \  -H "Authorization: Bearer $ATTIA_API_KEY" \  -H "Idempotency-Key: 0192f3c4-5e21-7b0a-8c3d-2f4e6a8b0c1d" \  -H "Content-Type: application/json" \  -d '{"url": "https://hooks.example.com/attia", "events": ["job.created", "application.created"]}'

Kroppen er et JSON-objekt. url og events er påkrevd.

En kropp som ikke er et JSON-objekt, gir 400 med koden invalid-request. Det samme gjør et manglende felt, en URL som ikke er https, en hendelse som ikke står på listen eller er navngitt to ganger, et felt utenfor denne tabellen og enhver spørreparameter. errors navngir hver av dem.

Svaret er 201 med webhooken i data. Headeren Location har webhookens sti.

HTTP/2 201location: /api/v1/webhooks/0192f3d0-8a14-7e2b-b6c9-1d3f5a7c9e02

{  "data": {    "id": "0192f3d0-8a14-7e2b-b6c9-1d3f5a7c9e02",    "label": "Zapier",    "url": "https://hooks.example.com/attia",    "team_id": null,    "events": ["application.created", "job.created"],    "status": "enabled",    "disabled_reason": null,    "created_at": "2026-10-29T08:15:30.482913Z",    "updated_at": "2026-10-29T08:15:30.482913Z",    "secret": "whsec_MfKQ9r8GKYqrTwjUPD8ILPZIo2LaLaSw8uLtnSjhsL4="  }}

Lagre secret når du får den. API-et gir den bare i dette svaret, og et nytt svar på den samme Idempotency-Key gir null. Mister du den, kan en administrator kopiere den på siden til webhooken under Innstillinger → API.

I appen viser revisjonsloggen for arbeidsområdet medlemmet som eier nøkkelen, som den som opprettet webhooken, fulgt av «via API».

Et team medlemmet som eier nøkkelen, ikke kan se, gir 400 med invalid-request som navngir team_id. Svaret er det samme om teamet ikke finnes, er arkivert, hører til et annet arbeidsområde eller er et team nøkkelens teamtilgang utelater. En nøkkel som er begrenset til noen team og ikke sender team_id, får det samme. Et arbeidsområde som allerede har 50 webhooks, eller et team som har 30, gir 409 med webhook-limit-reached. Et arbeidsområde som er kun for visning, gir workspace-view-only.

Avslutt abonnementet⁠

curl -X DELETE "https://attia.app/api/v1/webhooks/0192f3d0-8a14-7e2b-b6c9-1d3f5a7c9e02" \  -H "Authorization: Bearer $ATTIA_API_KEY" \  -H "Idempotency-Key: 0192f3d6-1b7e-7f40-a2c5-8e9d0f1a2b3c"

Svaret er 204 uten kropp. Webhooken og hemmeligheten er borte, og revisjonsloggen viser slettingen «via API». Nøkkelen til enhver administrator kan slette enhver webhook i arbeidsområdet, også en som en annen administrator satte opp, og et arbeidsområde som er kun for visning, kan fortsatt slette.

En id arbeidsområdet ikke har noen webhook for, gir 404 med not-found, og det gjør også id-en til en webhook i et annet arbeidsområde. Enhver spørreparameter gir 400 med invalid-request. Attia ser bort fra en kropp.

Send igjen trygt⁠

Kallene som abonnerer og avslutter, trenger headeren Idempotency-Key. Velg en ny verdi for hvert kall: 1 til 255 bokstaver, sifre, - eller _. En UUID fungerer. Et kall uten den gir 400 med idempotency-key-required.

Når et kall får tidsavbrudd eller forbindelsen brytes, sender du det igjen med den samme nøkkelen. Innen 24 timer endrer den samme nøkkelen med den samme forespørselen og den samme API-nøkkelen ingenting. Den får det første svaret tilbake, pluss headeren Idempotency-Replayed: true. Et gjentatt abonnement svarer med webhooken slik den ble opprettet, med secret satt til null. En gjentatt avslutning svarer 204 igjen. Rekkefølgen på feltene i kroppen spiller ingen rolle, men en endret verdi gjør det.

Den samme nøkkelen med en annen forespørsel eller en annen API-nøkkel gir 422 med idempotency-key-reused, og det gjør også den samme nøkkelen etter 24 timer, inntil 90 dager. En forespørsel som ble avvist, lagrer ingenting, så du kan sende den igjen med den samme nøkkelen når du har rettet årsaken.

List opp webhooks⁠

GET /api/v1/webhooks lister webhookene i arbeidsområdet, eldste endring først. Det gjelder også de som er av, og de en administrator har satt opp under Innstillinger → API. Nøkkelen til enhver administrator får alle webhookene, uansett hvem som satte dem opp, og det samme gjør en nøkkel som er begrenset til noen team.

curl "https://attia.app/api/v1/webhooks?limit=50" \  -H "Authorization: Bearer $ATTIA_API_KEY"

Alle de tre spørreparameterne er valgfrie.

En parameter utenfor denne tabellen gir 400 med koden invalid-request. Det samme gjør en parameter som er sendt to ganger.

Svaret har webhookene i data, sortert etter updated_at og så id. Hver har feltene fra svaret på abonnementet, unntatt secret, som ingen lesing gir. next_cursor er en streng når det finnes flere webhooks, og null på siste side. Send den tilbake som cursor til den er null. Paginering forklarer sorteringen.

Hent en webhook⁠

GET /api/v1/webhooks/{id} gir webhooken med den id-en, på eller av, i data med de samme feltene som en webhook i listen. Den tar ingen spørreparametere, så en parameter gir 400 med koden invalid-request.

curl "https://attia.app/api/v1/webhooks/0192f3d0-8a14-7e2b-b6c9-1d3f5a7c9e02" \  -H "Authorization: Bearer $ATTIA_API_KEY"

En id arbeidsområdet ikke har noen webhook for, gir 404 med not-found, og det gjør også id-en til en webhook i et annet arbeidsområde og en id som ikke er en UUID.

Eksempelhendelser⁠

GET /api/v1/webhooks/samples/{event} gir opptil tre hendelser av én type, nyeste først, i formen en levering sender. Attia bygger dem av postene i arbeidsområdet når du kaller. De er ikke tidligere leveringer, og Attia sender og lagrer ingenting. En Zapier-trigger viser dem i testtrinnet sitt.

curl "https://attia.app/api/v1/webhooks/samples/job.deleted" \  -H "Authorization: Bearer $ATTIA_API_KEY"

Svaret har eksemplene i data. Listen er tom når nøkkelen ikke når noen post for hendelsen.

{  "data": [    {      "id": "6b3881d8c00f6fd87a89e09f065925f96319d4797975f902b634b972d13eed99",      "type": "job.deleted",      "version": "v1",      "timestamp": "2026-10-01T09:42:10.118305Z",      "workspace_id": "0192f39e-02b1-7a5c-9d3e-4f6a8b0c2d1e",      "revision": 5,      "data": { "id": "0192f3a1-6b02-7d4c-8e11-5a9c0b7d3e01" }    }  ]}

Hver hendelse leser sine egne poster og tar de tre som sist ble endret:

• job.created og job.updated: stillingene GET /api/v1/jobs?include_archived=true lister for nøkkelen.
• job.deleted: slettede stillinger i teamene nøkkelen når.
• application.created, application.status_changed og application.updated: søknadene GET /api/v1/applications lister for nøkkelen.
• application.deleted: slettede søknader i teamene nøkkelen når.
• candidate.erased: kandidatene som er slettet for godt fra arbeidsområdet.

En søknadshendelse trenger også Lese kandidatdata og at Kandidatdata i API-et er slått på, fordi Attia bare sender søknadshendelser mens bryteren er på. candidate.erased trenger Lese kandidatdata, men ikke bryteren, fordi den sendes uansett. En nøkkel uten dem får 403 med insufficient-scope. En nøkkel som er begrenset til noen team, får bare eksempler fra de teamene, og en tom liste for candidate.erased, siden en kandidat ikke hører til noe team. En webhook satt til ett team får likevel selve hendelsen.

En hendelse som ikke står på listen, gir 404 med not-found. Enhver spørreparameter gir 400 med invalid-request.

Zapier⁠

I en Zapier-trigger av typen REST Hook:

• performSubscribe sender POST /api/v1/webhooks med url satt til bundle.targetUrl, hendelsene til triggeren og en ny UUID som Idempotency-Key. Returner data fra svaret, så tar Zapier vare på webhookens id i bundle.subscribeData.
• performUnsubscribe sender DELETE /api/v1/webhooks/{id} med bundle.subscribeData.id og en ny UUID som Idempotency-Key.
• perform får hver forespørselskropp Attia sender, i formen som står i Kom i gang.
• performList sender GET /api/v1/webhooks/samples/{event} med hendelsen til triggeren og returnerer data fra svaret. Zapier viser eksemplene når noen tester triggeren.

Webhooken handler som medlemmet som eier nøkkelen Zapier har. Den slås av når det medlemmet forlater arbeidsområdet eller ikke lenger er administrator. Koble til Zapier med nøkkelen til en administrator som blir værende.

I et Zapier-søk sender perform GET /api/v1/jobs/{id}, GET /api/v1/applications/{id} eller GET /api/v1/candidates/{id} og returnerer data fra svaret i en liste med ett element. Ved 404 returnerer den en tom liste, som er måten et Zapier-søk sier at det ikke fant noe på.

I en Zapier-handling sender perform POST /api/v1/jobs med en ny UUID som Idempotency-Key og returnerer data fra svaret. Hver kjøring sender en ny nøkkel, så en kjøring du spiller av på nytt i Zapier, oppretter en stilling til.