Error tracking: how do source maps work for my JS errors?

When a JavaScript error happens in production, the stack trace points into your minified bundle (main.a8f42b.js:1:42819). That's useless for debugging. Source maps are the JSON files your bundler emits that tell us how to translate those line/column numbers back to your original source.

Error tracking — and source maps with it — is available on Pro plans and above.

How source maps work in Zenovay

1. Your build produces a bundle (e.g. main.a8f42b.js) and a corresponding source map (main.a8f42b.js.map).
2. You upload the source map to Zenovay through the error-tracking API.
3. When an error arrives, the tracker matches it against your uploaded maps using the bundle file and the release you uploaded under.
4. The dashboard displays the original file, line, column, and a code snippet.

Source maps are stored against a release identifier — a Git SHA, a semver tag, or any string you choose. If an incoming error's release doesn't match an uploaded map, you'll see the minified line in the dashboard.

Uploading source maps

Source maps are uploaded via the error-tracking API. The endpoint takes a JSON body:

POST https://api.zenovay.com/api/errors/{websiteId}/sourcemap

Field	Required	Description
fileName	yes	The name the map should be stored under (e.g. main.js)
fileUrl	yes	The public URL of the bundle the map belongs to
release	recommended	The release identifier this map applies to (omit and it's stored under default)
mapContent	recommended	The contents of the .map file
mapUrl	optional	A URL the map can be fetched from, instead of inlining mapContent

These endpoints require an authenticated Zenovay session — pass your dashboard access token as a Bearer token (the short-lived token your browser uses when you're signed in to app.zenovay.com). They are not reachable with a zv_* REST API key.

curl -X POST "https://api.zenovay.com/api/errors/{websiteId}/sourcemap" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d @- <<'JSON'
{
  "fileName": "main.js",
  "fileUrl": "https://example.com/static/main.js",
  "release": "v2.4.1",
  "mapContent": "<contents of main.js.map>"
}
JSON

To see what's already uploaded for a site, list your maps:

GET https://api.zenovay.com/api/errors/{websiteId}/sourcemaps — add ?release=v2.4.1 to filter to one release.

Run the upload right after each production build so every release ships with maps, and check the response status so a failed upload is caught rather than silently skipped. Note that the access token is short-lived, so it needs to be fresh each time you upload — a session token captured from the dashboard won't stay valid for long.

About the release identifier

The release field is the link between a captured error and an uploaded map. Errors are stored with whatever release value they were reported under, and a map is matched to an error when both share the same release.

If you want errors tagged with a release in the dashboard, your application needs to report that release with each error it sends. Upload maps under the same identifier, and the two line up.

Verifying it works

1. Upload a map, then trigger a known error in production.
2. Open your website's dashboard, go to the Errors tab, and open the error.
3. The stack-trace section should show your original file path (e.g. src/components/Checkout.tsx:42) and a short code preview.

If it still shows the minified line, check:

• The release the error was reported under matches the release you uploaded the map under.
• The fileUrl you uploaded matches the bundle the error came from.
• The .map file isn't truncated (a partial upload can leave you without a usable map).

Privacy

Source maps contain your full original code. They're stored privately in object storage, scoped to your website, and never served publicly.

Related reading

• JavaScript errors overview
• Reading stack traces
• Error groups