Harden your intake webhooks

Treat intake URLs like production ingress — team-scoped keys, careful secret handling, idempotent payloads, and callback caution — so automation can't ransom workflows or leak Bearer tokens into logs.

Plus: three Admin Agent rehearsals — name-by-name risk review of your intakes, incident checklist when a key leaks, callback receiver threat model in five bullets.

Audience	Admins · Developers
Time	~8 min
Prerequisites	A working intake ([Trigger a workflow with an intake webhook](/tutorials/trigger-a-workflow-with-an-intake-webhook)). Comfort storing secrets outside git (CI secrets manager, vault). Vocabulary for `user.` vs `team.` keys ([Pick personal or team API keys for real work](/tutorials/pick-personal-or-team-api-keys-for-real-work)). Business/Enterprise if you rely on team-scoped intakes per product docs.
You'll end up with	Concrete guardrails — separate keys per caller, least-privilege team attachment, JSON idempotency discipline, and a deliberate deactivate-vs-delete choice — matched to what [Intake Webhooks](/docs/integrations/intake-webhooks) actually authenticates today (Bearer-only ingress).

When a tutorial shows italic text in quotation marks, it usually mirrors a label or helper string inside Auxot. Product copy changes between releases — if something reads differently in your workspace, trust what you see on screen.

Callouts with a Worth knowing gold accent are meant as must-read context before you move on. Blockquotes that open with Tip are lighter, optional depth.

Why this matters

An intake URL is POST-anywhere ingress: whoever holds a valid Bearer token and guesses or learns your INTAKE_ID path shape can enqueue workflow work. Auxot does not issue shared-secret HMAC headers for callers in the public manual today: security comes from key custody, network path, team scope, and how you design payloads (Intake Webhooks, Authentication & API Keys).

Good discipline turns “Zapier experiment” into something ops can sleep through: team. keys for shared automation, one key per upstream service, structured bodies that tolerate retries, and calm deactivation (404 without confirming whether the URL exists; documented behavior).

Auxot does not deactivate intakes for you. You revoke keys, deactivate intakes, and fix workflows when something looks wrong.

Quick start

Bearer belongs in secrets storage: CI/GitHub Actions encrypted secrets, Lambda env from KMS; never repo plaintext (Authentication & API Keys).
Prefer team. keys on Business/Enterprise: they scope service identity to the team owning the intake (Intake Webhooks).
One intake per integration slice: if Zapier is compromised it should not share a URL shape with your prod billing rebuild path.
Add caller-owned idempotency: include a stable request_id or ticket id inside JSON; the workflow’s first step dedupes or no-ops duplicates you designed for.
HTTPS end-to-end: terminate TLS correctly and forbid accidental http:// leakage in redirect chains.
Deactivate intakes you no longer use: paused intakes return 404 to callers without confirming whether the URL exists; use during migrations (Intake Webhooks).

Done? A threat-model paragraph you could paste into a SOC review (ingress auth, leak impact, and rotation) without promising crypto Auxot doesn’t document.

The agent can do that?

1. Name-by-name risk review

Chat → Admin Agent:

Intake names + owning teams: [paste list]. Flag overlapping workflows, generic names, or cross-team coupling risky if one upstream leaks.

Why it’s non-obvious: The names you give intakes affect how cleanly you can split them later. You still rename or split intakes after reading the reply.

2. Leaked key choreography

Assume partial leak of intake Bearer + ID discovered in CI logs. Ordered response: revoke key, audit window ([Trace a failing job end to end](/tutorials/trace-a-failing-job-end-to-end)), rotate, and notify owners; UI clicks named.

Why it’s non-obvious: Revoke first, then investigate. Run this rehearsal before the on-call alert wakes someone up.

3. Callback receiver threat model

Our intake callback hits https://api.internal/acme/auxot-callback: draft five-bullet receiver checklist (TLS, auth, payload size, replay, and logging redaction).

Why it’s non-obvious: Callback POSTs are outbound from Auxot; your receiver must treat them like untrusted internet unless network policy says otherwise; Admin Agent lists controls you implement.

Go deeper

What Bearer does not solve

Bearer proves key possession, not specific upstream vendor identity. If GitHub Actions can call your intake, anyone with the repo secret can; protect repo branch protections and secret visibility.

Retries = duplicate work unless you plan

HTTP clients retry 5xx / timeouts; the same JSON may arrive twice. Encode natural keys (ticket id, commit SHA) and design workflow or agent steps that recognize repeats.

Callback URLs

When a workflow completes, it may POST results to your URL (Intake Webhooks). Harden the receiver:

HTTPS only
Authenticate (mTLS, shared header secret you validate, allowlist Auxot egress IPs if static in your environment)
Rate-limit and size caps
Log metadata, not full PII bodies

Operational checklist (copy block)

Key stored only in secret manager / CI secrets
Key named after service (team.zapier-signup-prod)
Intake assigned correct team (Business/Enterprise)
Workflow human steps aligned with worst-case automated spam
Monitoring: failed jobs visible (Trace a failing job end to end)
Runbook line for deactivate and 404 expectation

Walkthrough

Step 1: Inventory callers

Spreadsheet: Upstream | INTAKE_ID | Key prefix | Secret location | Owner.

Step 2: Replace shared personal keys

Swap lingering user. production paths per Pick personal or team API keys for real work; create dedicated team. keys (Create a shared Team API Key).

Step 3: Tighten JSON contract

Document required fields and external_id uniqueness; publish internally so Zapier field maps stay honest.

Step 4: Exercise retry safety

Replay identical POST in staging; confirm workflow doesn’t double-charge external side effects.

Step 5: Callback hardening

If enabled: implement receiver auth and structured logging without secrets.

Step 6: Test the deactivation

Toggle intake off → confirm caller receives 404 → document restore path.

What’s next

→ Trigger a workflow from GitHub Actions. Secrets + YAML pattern once intake semantics are understood.
→ Accept your invitation and join your organization. Share the public invitee path with anyone joining while you own Bearer discipline on intakes.
→ Trigger a workflow with an intake webhook. Happy path POST + poll when hardening basics hold.
→ Pick personal or team API keys for real work. Key taxonomy before spinning more intakes.
→ Trace a failing job end to end. Evidence after suspicious traffic patterns.
→ Red-team your agents against prompt injection. HTTP ingress is part of the adversarial surface; pair hardening with rehearsal.
→ Security. Broader encryption and auth model for self-hosted installs.

Reference

Manual: Intake Webhooks, Authentication & API Keys
Pages in Auxot: Settings → Intakes
See also: Trigger a workflow from GitHub Actions, Accept your invitation and join your organization, Create a shared Team API Key, Rotate credentials without surprising your agents