SDKs & platforms overview

For agents: list_keys returns the DSN to paste into any snippet; create_project takes a platform id from the table below. Example: list_keys(org="acme", project="checkout-api"). For the exact init code call get_doc(slug="sdks/javascript") (or the family page you need).

Bugwatch works with the official Sentry SDKs. Nothing is forked or re-published: install the SDK for your framework, point it at a Bugwatch DSN, and keep your code. Bugwatch is not affiliated with Sentry; compatibility is with the envelope protocol those SDKs speak.

The DSN

https://<public_key>@ingest.bugwatch.io/<project_number>

• public_key is a 32-hex key created with the project (list_keys / create_key). Disabling a key rejects its traffic within about a minute.
• project_number is the immutable numeric id SDKs require in the path (starts at 1001).
• Ingest endpoint the SDKs post to: POST https://ingest.bugwatch.io/api/<project_number>/envelope/, authenticated by the X-Sentry-Auth header (sentry_key=…) or a ?sentry_key= query parameter. Bodies may be gzip or deflate compressed; the decoded envelope is capped at 1,000,000 bytes (413 above that).

What the ingest endpoint accepts

Attachments

Screenshots, view hierarchies, log files and any other file an SDK attaches to an error or transaction are stored with that event, before the request is answered, like the event itself.

• Up to 20 per event, within the request's 1 MB limit. Larger files (most minidumps) do not fit through ingest yet.
• Metered in bytes, not as events. Every plan includes attachment storage per month (Free 100 MB, Starter 1 GB, Team 5 GB, Business 20 GB, Scale 50 GB). Past it, attachments are dropped and counted until the period resets, while every event keeps flowing. There is no overage on attachments.
• Kept as long as their event: 30 or 90 days by plan, then deleted automatically. Deleting the organization deletes them too.
• Counted when not stored: an attachment with no error or transaction in the same envelope (no_event), one past the allowance (attachment_quota) or past 20 (too_many) is recorded in your usage data with that reason.

On the issue page, the right-hand rail lists the files attached to the issue's events, each with its size, as a download link. Over the API: GET /v1/orgs/{org}/projects/{project}/issues/{shortId}/attachments lists them (tool: list_issue_attachments, event:read), and GET /v1/orgs/{org}/projects/{project}/attachments/{id} returns the file.

A download is always a download. The bytes are whatever an SDK sent, so the file is served as application/octet-stream with Content-Disposition: attachment, X-Content-Type-Options: nosniff and a sandboxing Content-Security-Policy. An HTML or SVG "screenshot" cannot run in the dashboard's origin, and a filename can never carry a path or end the header. An attachment whose event has expired answers 404 saying so, rather than an empty file.

Profiles, replays and feedback are not stored

Sentry SDKs can also send profiles, session replays and user feedback. Bugwatch does not store any of these yet.

The envelope is still accepted and the event beside them is stored normally. Nothing errors, because a hard failure on an item type we do not recognise would break ingest for everybody every time Sentry adds one — the event you care about would be lost along with the attachment you did not.

What changed is that the drop is now counted: each one is recorded in your usage data as unsupported, with the item type as the reason, so "we are throwing away 40 MB of replays a day" is a question with an answer. Types we have never seen are recorded as unknown_type, which is a different thing from a gap we know about.

If you rely on profiles or replays today, this is the compatibility gap worth knowing about before you migrate.

Responses: 200 {"id": "<event_id>"} on success; 401 unknown key; 403 disabled key; 429 when the organization is over quota, with X-Sentry-Rate-Limits: <retry_after>:<categories>:organization and Retry-After so SDKs back off; 503 if the queue is briefly unavailable (SDKs retry).

Platforms

Every entry links to its family page with the init snippet and lifecycle notes.

Pass the platform id to create_project (or pick it in the dashboard) so issues get the right stack-trace conventions and the project page shows the matching snippet.

Next

• Source maps & symbolication — debug IDs, sentry-cli compatibility, release association.
• Filters & scrubbing — what is dropped or masked before storage.
• Quickstart — first event in five minutes.