Subject: bug
Something is broken
A capture that never arrived, a body rendered wrong, a dashboard that stopped updating. These are the most useful messages to send, because a bug nobody reports is a bug nobody can see.
Contact · one inbox, read by a person
Get in touch.
There is no ticket system, no chat widget and no contact form — a form would only turn your message into an email anyway, and collect your address to do it. So here is the address directly.
Written in full rather than hidden behind a script, so it works with the keyboard, a screen reader and a browser with JavaScript switched off.
What this inbox is for.
Subject: abuse
Abuse of the service
A SnapHook URL being used for phishing, as a relay, or to flood something you run. Include the full URL and roughly when, and the session behind it can be killed outright.
Subject: security
A security problem
Anything that lets one person see another person's captures, or otherwise breaks the promises these pages make. Report it privately here first and it gets fixed before it is described anywhere public.
Before you write
Two things answer most questions faster than an email can. The documentation covers the capture limits, reading a capture and how to point a real provider at an endpoint, and its frequently asked section covers what comes up most: why a session vanished, what the payload limits are, and whether any of this is logged.
The commonest surprise is not a bug. Sessions are purged after 2 hours of inactivity, and whenever the service is restarted. So a session that vanished while you were not looking at it has almost certainly expired rather than failed.
What to include
A report that can be reproduced gets fixed; one that cannot usually cannot be acted on at all. Where it applies, the useful details are:
- what you sent — the method, the sub-path, roughly the body size and content type
- what you expected to see, and what the dashboard actually showed
- roughly when it happened, in UTC if you know it
- the browser, if the problem is in the inspector rather than in the capture
A session slug is only worth sending for an abuse report, where it identifies what to shut down. For a bug it is rarely useful — the session is very likely gone by the time the message is read.
What not to send
Please do not email a session URL that still holds real data, and do not attach captured payloads containing credentials, tokens, payment details or anybody's personal information. The reasoning is the same as on the privacy page: the service is built to hold as little as possible for as short a time as possible, and mailing a copy of a capture to a Gmail inbox undoes that in one step. Redact it, or describe it instead.
Nothing you send to this address is added to a mailing list, because there is no mailing list. There is no newsletter, no product announcement and no account to be subscribed to.
What to expect
SnapHook is run by one person as a free service, so this is worth saying plainly rather than implying otherwise: replies are best-effort, and there is no response-time commitment and no support contract. A security report or a live abuse complaint gets looked at first. Everything else is answered when there is time, and some messages will not be answered at all — a feature request that is not going to be built is more honestly left unanswered than refused at length.
Everything else
Licensing questions, anything about the terms of use, and anything that needs a human rather than a form all go to the same address. What the service may and may not be used for is set out in the terms of use.
Nothing to report?
Then there is nothing to read here. Your endpoint is one click away.