Skip to main content
Webhook routing is provider-owned configuration. A route implemented by the Engine does not prove that Twilio, Postmark, or any other provider currently targets it.

Durable routing rule

Every external intake route is bound to one named provider, source channel, target environment, API base, and path. Canon may call that routing current only when the provider configuration or an accepted provider receipt has been read and dated.
Do not infer one provider’s destination from another provider, a reachable hostname, source code, an older screenshot, or the existence of a Staging service.

Verified implementation boundary

Engine dev source at e2166b86ac6794a1423c7b2ce1b293a3dba505c4 implements the maintenance intake path intended for the Development API base:
That proves a source-implemented route, not a provider destination. The Twilio and Postmark provider consoles were not re-read on 2026-09-10, so no fresh claim is made that a particular SMS, MMS, WhatsApp, or inbound-email source currently points there.

Nothing writes to the inbox unauthenticated

Every branch of the maintenance intake route authenticates before it writes (LUCI-169, verified in the route source at the commit above):
A request on the generic branch without the secret is refused with the authentication error and nothing reaches the inbox store. The secret’s value is never published; its name is the contract. Which mail this route sees: Postmark carries the employee-facing maintenance thread only. Guest-facing mail (the booking magic link and the payment request) leaves through Resend and never enters this route. See Email Services.

Environment posture

Development is the active Engine integration environment. Engine Staging exists at its own API base, but is an older, manually promoted deployment. Routing a provider to Staging is an intentional provider-side change and must be verified independently; Staging existence does not make it the current provider target. A deliberately local provider test may require an intentional tunnel and a temporary provider configuration. A localhost or tunnel destination must never be documented as shared current routing after that test ends.

Required evidence record

For each provider and source channel, record:
If any field is unknown or stale, label that provider route unverified. Do not fill the gap with a fleet-wide routing statement.

Change discipline

Before switching an external intake route:
  1. Verify the target service identity and implemented path.
  2. Capture the provider’s existing destination and rollback value.
  3. Change only the named provider resource.
  4. Validate one controlled delivery without broadening mutation scope.
  5. Record the provider receipt, timestamp, result, and rollback posture.
Provider console changes are external effects and require explicit owner authorization plus a documented verification and rollback plan.

See also