When the target system has no Zapier app — a Rewst workflow, an internal automation server, a
vendor's inbound hook — a raw webhook is the last-resort transport: powerful and structureless —
no field validation, no find-before-create, no vendor semantics. Impose the structure it lacks.
This is the escape hatch, not the default: where a named Zapier app covers the target, use it —
apps carry validation and lookups raw webhooks lack.
It runs only if the member has connected Zapier with the Webhooks action enabled, and that is
deliberate: it can call any URL, so some tenants exclude it on purpose. If it's absent, apply the
Connector Degradation base skill — output the composed payload and endpoint name for the member
to fire from their own automation platform, and note the pending trigger on the ticket. Each
Zapier call costs 2 Zapier tasks.
1. Verify before promising. Confirm the Webhooks action (POST, PUT, GET) is enabled here, then
that the endpoint is known and documented: the member or tenant runbook supplies the URL,
method, content type and payload contract. No documented contract, no fire — guessing a
payload triggers automations with guessed data. Never fire at a URL improvised from memory or
scraped from an old ticket.
2. Keep URLs and headers secret-free. Auth material belongs in the tenant's stored config —
curated-server locked fields, or the receiving system's own validation — never inline in
output or pasted into a note. If the endpoint's design forces a secret-bearing URL, treat the
whole URL as a credential: use it, don't quote it.
3. Compose the payload with discipline: exactly the fields the contract specifies, with stable
names, ISO-8601 timestamps, the Thread ticket reference for traceability, explicit nulls, and
an idempotency-friendly key (ticket number plus event type) wherever retries are possible. No
padding — client data takes the same minimum-necessary, no-credentials sanitization as any
external write.
4. Show the endpoint by name (not the secret-bearing URL), the method and the full payload,
before firing.
5. Fire it and read the response honestly. A 2xx means the endpoint accepted the request, NOT
that the automation succeeded — report it that way ("the workflow endpoint accepted the
trigger", never "the onboarding completed") and capture any returned job or run id. On a
non-2xx or timeout, report the actual status and body minus secrets, and do NOT retry blindly:
it may have processed despite the error, and duplicate triggers do real work twice.
6. Leave a note — plain text, no markdown or emojis (PSA Note Discipline base skill): endpoint
name, a summary of what was sent rather than secret detail, response status, any returned id,
and honest wording — "accepted", not "done". Name where confirmation will actually appear: a
Rewst notification, a status page.
Magic Library