How We Built a Single Intake API for Every Request

Building one Intake API for every request forced clear choices: a single route, strong auth, and a rule that only action_required creates tickets.

Why /api/v1/intake

• One path for every source (email, forms, CRM, chat, compliance).
• Stable contract for partners and internal teams.
• Versioned so we can evolve without breaking clients.

Why HMAC

• No client secrets in query params; no OAuth sprawl for webhooks.
• Protects against tampering and replay with timestamp + body hash.
• Easy to rotate and scope per integration (allowed IPs, expiry).

Why “ticket only if action_required”

• Keeps feedback/observations as signal; work queues stay clean.
• Prevents ticket inflation from FYI or low-signal submissions.
• Drives better metrics: fewer stale tickets, clearer SLA compliance.

Why feedback is not always a ticket

• Feedback is evidence; tickets are commitments.
• Storing feedback separately surfaces product signals without burning support cycles.
• Agents stay focused on work that needs action.

System pattern

• Normalize payloads, classify intent/priority/action_required.
• Dedupe open work; merge follow-ups into the same thread.
• Route by rules; log decisions for audit.

One Intake API plus disciplined rules turns every request into clean, auditable work—or keeps it as signal when no action is needed. See the Intake API spec.