Ingress: OAuth & Webhooks
42 API route handlers in the webapp. They do not share one trust model. This page records exactly which ones the auth proxy protects and what the others do instead.The trust boundary
The matcher (apps/webapp/proxy.ts:288):
Exempt routes — verified, one by one
Every exempt route was checked. None are unintentionally open.All eight non-health exempt routes verify a provider signature before doing any work. The
exemption is a deliberate design — webhook senders have no Auth0 session — not an oversight.
OAuth callback flow
Provider connection is initiated from the settings UI and completes through a callback that is behind the auth proxy — so the completing user is always an authenticated organisation member. Participants:Setup page = setup/integrations/[provider]/[id],
Callback = api/[provider]/callback,
install.ts = lib/integrations/[provider]/install.ts.
Core-side token handling lives in the otto-oauth, stripe-app-oauth, and finapi
domains of @cona/core.
Route inventory
stripe-app/callback is an OAuth callback but is counted under Stripe App because it is
exempt from the proxy while the other 11 callbacks are not.
Notes
Data does not enter through these routes. Marketplace and payment data is pulled by Temporal activities, not pushed to the webapp. Webhooks here are GDPR requests and Stripe billing events only. See Integrations./dev and /api/dev return 404 outside dev and staging — enforced in proxy.ts:237-248,
after the session check.
Privileged access is audit-logged. Requests to /admin and /dev emit a security
event (proxy.ts:251-259) to the Axiom security dataset.
The portal has a separate ingress model entirely — no middleware, share token plus
postal-code verification. See Portal.