Customer portal

Give each tenant a self-serve surface for endpoints, catalog, and delivery debugging so their eng team does not email you at 2am.

Why a portal

Your customers own the HTTPS URLs. They change infra, rotate secrets, and need to see why a delivery failed. The portal is first-class: branded short link or embed, scoped to one application.

Access model

Exchange path: /p/{appId} with portal key material you mint per application
Short-lived session token under /portal/{token}
Portal users never see your org API keys (sk_*)

Create applications and portal links in the dashboard under Applications. Store the reveal-once portal key securely.

Capabilities

Typical portal capabilities (gated by flags):

List and create endpoints for that application
Browse the event catalog and example payloads
View deliveries / attempts for their endpoints
Replay a message (creates new deliveries)
Read-only mode for support-safe sharing

Replay only in portal

The portal exposes Replay, not Retry. Retry stays a vendor-dashboard / API operation on a specific delivery.

Embed / link

Ship a "Manage webhooks" button in your product that opens the exchange URL or an iframe to the portal session. Example shape:

text

https://outemit.dev/p/app_01HXYZ
# after exchange → short-lived
https://outemit.dev/portal/<token>

Keep capability flags tight for early customers (read-only deliveries + catalog) and expand as they need self-serve endpoint edits.

Security notes

Treat portal keys like passwords; rotate if leaked
Sessions are short-lived; do not log raw tokens
Portal cannot switch livemode or read other applications
Signing secrets for endpoints follow the same reveal-once rules as the vendor dashboard

Related: Signing and verify for what your customers implement on their receivers.