Automate Transept with webhook triggers

Open a saved workflow in the builder and look at the trigger card at the top — the one that reads You run it manually. It’s a switch. Manual is the default: you press Run yourself. Webhook hands the workflow a private URL that an outside system POSTs to, so the run starts on its own. A trigger belongs to a saved workflow, so save the workflow first — the Webhook option stays disabled on an unsaved draft.

Switch the card to Webhook, set what the fire runs on (below), and save. Transept mints a secret URL for this one workflow and shows it once — copy it then, because only a hash is stored and the full URL can never be shown again. The secret lives in the URL rather than in a header, because the simplest senders can’t set headers; so treat the URL like a password — anyone who has it can start the run.

Reopen the card later and you see a masked prefix (whk_live_…) in place of the full URL, plus a Rotate action. Rotating mints a fresh URL and breaks the old one the instant you confirm, which is how you retire a link that leaked. You can also switch the trigger off without deleting it, or remove it outright. The card shows when it last fired.

Two settings decide what the workflow touches when the URL is hit:

• Target — a fixed document you name (every fire lands on that document and its language group), or the Notion page named in the incoming payload (Transept matches it to your document, importing the page the first time it sees it).
• Languages — all language versions (the default; the run fans across every language of the target as a group run), or just the one document.
• Only updated content — on by default, because an automated run should redo only what changed since last time, not re-translate the whole document on every fire. See Run only what changed.

A Notion database automation can call the trigger with its Send webhook action: point the action at the trigger URL, and each time the automation runs, Transept runs the workflow on the page that fired. Two things are worth knowing before you rely on it.

First, Notion automations fire on a property change (or a new page), not on a body edit alone — so editing a page’s text may not fire anything. The reliable pattern is a Status property the automation watches: flip it (say, to Ready to translate) and that change is the signal.

Second, a Notion webhook only names the page — it never carries the page’s content — so Transept reads the page through your Notion connection, which has to be granted access to the database inside Notion. Both steps (connect Notion, then share the database with the integration) are written out in the “Notion triggers: give Transept access” section of Automate Transept with the API. Skip either and every fire is turned away with an access error.

Anything that can send an HTTP POST can fire the trigger — a Zapier or n8n step, a CI job, a curl at the end of a build. For a fixed-document target the body doesn’t matter, so an empty POST is enough; only a Notion page target reads the body, to learn which page changed. No Authorization header is needed — the secret is the whole URL.

By default a fire runs the workflow across all language versions, and — with Only updated content on — re-translates only the blocks whose source changed since the last run, so a small edit costs a handful of blocks, not the whole document. Runs started this way bill words exactly like the in-app editor, and if the balance can’t cover the run nothing is dispatched and nothing is billed.

A step set to wait for your review still parks: the fire translates up to that gate and then holds, and the language shows up in the editor’s Reviews-ready panel for you to approve — automation doesn’t skip your review gates. And when a Notion page target can’t be read (usually because the database wasn’t shared with the integration), the trigger card surfaces the last failure as a “couldn’t read the Notion page” note, timestamped, so you can see why a fire did nothing.