Support

Something not working, or not working the way you expected? Send it over and include what the app can tell us.

Contact

Tell us what you were doing, what you expected, and what happened instead. If the app produced a support bundle (below), attach it — it usually turns a week of back-and-forth into one reply.

What a support ticket from the app contains

SpotterCam's Support section builds a small bundle and asks you before it sends anything. It is a zip plus a short description, and you can open the zip and look at it first.

Native detection logs — the text log of what the detector decided and why.
Settings and tunables — the knob values in force, and the history of what changed them.
Build and machine info — version, build stamp, the camera in use, OS version.
Your description — what you typed into the ticket.
Optionally, evidence images for the shots in question — the small before/after crops the detector already made. Only if you tick that box.

What never leaves your box automatically. Colour stills, session recordings, the live stream, your target photos and your round history stay on your machine. Nothing is sent home in the background — a ticket goes only when you tap send, and a recording goes only if we ask for it and you choose to upload it.

For whoever builds the receiver Not live yet

This section documents the contract so the hosting side and the app side can be built independently. The endpoint below is not yet running; tickets go by email today.

Request

POST https://spottercam.com/support/ticket.php, as multipart/form-data:

Part	Type	What
`meta`	JSON text	Ticket metadata (below). Required.
`bundle`	file, `application/zip`	The logs/settings zip. Optional but normal. Cap 25 MB.

The meta JSON:

{
  "v": 1,
  "kind": "bug" | "question" | "feedback",
  "subject": "Ghost confirms on a windy target",
  "body": "free text the operator typed",
  "contact": "rob@example.com",
  "app": { "version": "1.4.2", "build": "2026-09-21T10:04:00Z", "sha": "0a52b5e" },
  "machine": { "os": "Windows 10 19045", "role": "field", "id": "<stable random per install>" },
  "session": { "recording": "session_rec_20260921_100400", "round": 3 },
  "bundle": { "name": "support_20260921_100400.zip", "sha256": "…", "bytes": 1841203 }
}

Response

200 { "ok": true,  "ticket": "SC-20260921-0007" }
413 { "ok": false, "error": "bundle too large" }
400 { "ok": false, "error": "bad meta" }
429 { "ok": false, "error": "rate limited" }

The app shows the ticket id to the operator and writes it to the log, so a later email can reference it.

What the receiver has to do

Validate meta as JSON and reject anything over a few KB.
Reject a bundle that is not a zip or is over the size cap, before reading it.
Store the pair under a generated ticket id, outside the web root.
Email Rob a notification with the subject, body and the stored path — not the zip itself.
Rate-limit per install id and per IP.
Never echo any submitted field back into an HTML page.

A worked PHP sketch of exactly that is in support/ticket.php.example in the site source. It is an example, not a deployment: read it, then decide what you actually want running.