Privacy & safety
Anyone who knows the catch URL can send traffic to that Inbox. Prefer HTTPS, avoid posting Inbox links in public channels, and create a new Inbox if a URL leaks.
Treat the catch URL as a secret
Captures may contain sensitive data
Requests often include:
- API keys or
Authorizationheaders - Cookies from the sender
- Personal or payment-related fields in webhook bodies
Good practice
- Limit who can sign in to your Spanline workspace.
- Do not forward production webhooks to a shared debug Inbox without approval.
- Delete the Inbox (or clear requests) when finished.
- Use dedicated test credentials whenever possible.
When sharing screenshots or HAR exports: redact tokens, emails, and payment fields; prefer staging Inboxes.
What is public vs what needs sign-in
| Action | Who |
|---|---|
| Send traffic to the catch URL | Anyone with the URL |
| Open Capture, change mock responses, delete data | Signed-in workspace members |
Platform operators with directory-wide read access follow your organization’s policy; day-to-day Capture management still requires workspace membership.
Mock responses
If you return HTML from a mock response, configure Content-Type carefully and never put real secrets in mock bodies. Catch responses are meant for debugging, not for hosting private content.
Replay caution
Edit & Replay sends HTTP from the browser you are signed into. Absolute URLs can reach internal or production hosts if you paste them. Strip or replace auth headers when testing, and never replay production tokens to untrusted URLs.
Tips for teams
- Rotate by creating a fresh Inbox when credentials may have been exposed in a capture.
- Prefer short-lived debug Inboxes for production incident investigation.
- Export HAR only through approved channels — files can still contain secrets.
Related
- Getting started — first Inbox and catch URL
- Guides — inspect, mock, replay, export
- FAQ — auth headers visible, replay failures