ShipfoxHQ · ThierryAbalea · Jul 2, 2026 · Jul 2, 2026
diff --git a/ai/authoring-prompt.mdx b/ai/authoring-prompt.mdx
@@ -20,7 +20,7 @@ Trigger { source, event, filter?, with? }. For integrations, source is the
 CONNECTION SLUG (e.g. github_<org>, sentry_<org>, or your webhook slug), not the
 bare provider name; for on-demand runs it is literally "manual". Shipped events:
 manual/fire, github push (+ other GitHub events), sentry issue.(created|resolved|
-assigned|archived|unresolved), custom-webhook/webhook.received. At most one manual
+assigned|archived|unresolved), custom-webhook/received. At most one manual
 trigger.
 
 Job { steps (>=1), needs?, runner?, env? }. Jobs run in parallel; each is isolated
@@ -62,7 +62,7 @@ evaluated yet. event.ref on a push is the full Git ref (e.g. "refs/heads/main").
 The prompt is deliberately compact but complete. It covers every dimension of the shipped schema:
 
 - **Top-level schema fields** — `name`, `runner`, `env`, `triggers`, `jobs`, and which keys are rejected
-- **Trigger sources (shipped today)** — `manual`, plus integration connection slugs for GitHub (`push`), Sentry (`issue.*`), and custom webhooks (`webhook.received`)
+- **Trigger sources (shipped today)** — `manual`, plus integration connection slugs for GitHub (`push`), Sentry (`issue.*`), and custom webhooks (`received`)
 - **Job isolation and `needs` ordering** — parallel execution, repo re-cloning, and dependency chaining
 - **Step kinds: run vs. agent** — the two mutually exclusive step shapes and their allowed fields
 - **Gate / restart_from rules** — CEL expressions over `exit_code` and how to wire restart targets

diff --git a/concepts/runner-provisioners.mdx b/concepts/runner-provisioners.mdx
@@ -78,6 +78,10 @@ configured through environment variables:
 | `SHIPFOX_PROVISIONER_DOCKER_NETWORK` | no | Docker network to attach runners to |
 | `SHIPFOX_PROVISIONER_DOCKER_EXTRA_HOSTS` | no | Extra host mappings (e.g. `host.docker.internal:host-gateway`) |
 
+Create the provisioner token (`SHIPFOX_PROVISIONER_TOKEN`) on **Settings → Runner
+Provisioners** in the dashboard — the value is shown once, and you can revoke it
+there.
+
 Poll intervals, reservation limits, token batch size, and the registration deadline
 have sensible defaults and can be tuned with additional `SHIPFOX_PROVISIONER_*`
 variables.

diff --git a/concepts/triggers.mdx b/concepts/triggers.mdx
@@ -33,7 +33,7 @@ triggers:
 
 <ParamField path="event" type="string" required>
   The specific event from that source (for example `push`, `issue.created`,
-  `webhook.received`, or `fire`). Must be at least one character. Each integration
+  `received`, or `fire`). Must be at least one character. Each integration
   page lists the events it emits.
 </ParamField>
 

diff --git a/integrations/linear.mdx b/integrations/linear.mdx
@@ -23,7 +23,7 @@ integration emits.
 
 Linear can already reach Shipfox through a [custom webhook](/integrations/webhooks):
 create a webhook connection, point a Linear webhook at its ingest URL, and trigger
-on `webhook.received` — the run gets Linear's payload as its `event` context.
+on `received` — the run gets Linear's payload as its `event` context.
 
 ## Related pages
 

diff --git a/integrations/overview.mdx b/integrations/overview.mdx
@@ -40,7 +40,7 @@ and target each independently from different workflows.
 |---|---|---|
 | [GitHub](/integrations/github) | ✅ Shipped | `push` and other repository events |
 | [Sentry](/integrations/sentry) | ✅ Shipped | `issue.created`, `issue.resolved`, `issue.assigned`, `issue.archived`, `issue.unresolved` |
-| [Custom webhook](/integrations/webhooks) | ✅ Shipped | `webhook.received` |
+| [Custom webhook](/integrations/webhooks) | ✅ Shipped | `received` |
 | [Linear](/integrations/linear) | 🚧 Coming soon | — |
 | [Slack](/integrations/slack) | 🚧 Coming soon | — |
 | GitLab | 🔜 Roadmap | — |

diff --git a/integrations/slack.mdx b/integrations/slack.mdx
@@ -23,7 +23,7 @@ integration emits.
 
 Slack can already reach Shipfox through a [custom webhook](/integrations/webhooks):
 create a webhook connection and point a Slack outgoing webhook or automation at its
-ingest URL, then trigger on `webhook.received`. For the other direction, a `run`
+ingest URL, then trigger on `received`. For the other direction, a `run`
 step can post to a Slack incoming webhook today (`curl` to your Slack webhook URL).
 
 ## Related pages

diff --git a/integrations/webhooks.mdx b/integrations/webhooks.mdx
@@ -1,11 +1,11 @@
 ---
 title: "Custom Webhooks: Trigger Workflows from Any System"
 sidebarTitle: "Custom webhook"
-description: "Create a Shipfox webhook connection, point any system at its URL, and trigger workflows on the webhook.received event. The connection slug is your trigger source."
+description: "Create a Shipfox webhook connection, point any system at its URL, and trigger workflows on the received event. The connection slug is your trigger source."
 ---
 
 A **custom webhook** connection gives you a unique URL that any system can POST to.
-Every request that arrives fires the `webhook.received` event, which your workflows
+Every request that arrives fires the `received` event, which your workflows
 can trigger on. Use it for tools Shipfox doesn't integrate with directly — CI
 systems, monitoring, internal services, or anything that can send an HTTP request.
 
@@ -32,7 +32,7 @@ systems, monitoring, internal services, or anything that can send an HTTP reques
     Shipfox responds `202 Accepted` with a `delivery_id`.
   </Step>
   <Step title="Trigger a workflow">
-    Author a trigger using the connection slug as `source` and `webhook.received`
+    Author a trigger using the connection slug as `source` and `received`
     as `event`.
   </Step>
 </Steps>
@@ -43,10 +43,10 @@ systems, monitoring, internal services, or anything that can send an HTTP reques
 triggers:
   on_webhook:
     source: deploy_hook       # your webhook connection slug
-    event: webhook.received
+    event: received
 ```
 
-`webhook.received` is the only event a custom webhook emits — every request to the
+`received` is the only event a custom webhook emits — every request to the
 ingest URL fires it.
 
 ## Event payload

diff --git a/reference/trigger-sources.mdx b/reference/trigger-sources.mdx
@@ -17,7 +17,7 @@ integration page.
 | Manual | `manual` (literal) | `fire` | None — [Triggers](/concepts/triggers#manual-trigger) |
 | GitHub | connection slug, e.g. `github_acme` | `push` and other repository events | [GitHub](/integrations/github) |
 | Sentry | connection slug, e.g. `sentry_acme` | `issue.created`, `issue.resolved`, `issue.assigned`, `issue.archived`, `issue.unresolved` | [Sentry](/integrations/sentry) |
-| Custom webhook | connection slug you choose | `webhook.received` | [Custom webhook](/integrations/webhooks) |
+| Custom webhook | connection slug you choose | `received` | [Custom webhook](/integrations/webhooks) |
 | Cron | 🚧 Coming soon — `cron` (literal) | `tick` | [Triggers](/concepts/triggers#coming-soon) |
 | Linear | 🚧 Coming soon | — | [Linear](/integrations/linear) |
 | Slack | 🚧 Coming soon | — | [Slack](/integrations/slack) |