Switch Error Tracking Without Changing Code: How jentry Is Sentry SDK Compatible

Changing your error-tracking backend usually sounds like a migration project: swap the SDK, relearn an API, re-instrument every service, ship a release across your whole fleet, and hope nothing breaks. It doesn't have to be. Because jentry speaks the same wire protocol as the Sentry SDKs, you can switch error tracking without changing code — you repoint one URL and redeploy. This post explains exactly why that works, down to the bytes on the wire.

The one thing you actually change: the DSN host

Your SDK already knows where to send events. That destination is encoded in a single string called the DSN (Data Source Name). It looks like this:

# Before — pointing at Sentry's hosted ingest
https://abc123def456@o12345.ingest.sentry.io/4567

# After — pointing at jentry
https://abc123def456@jentry.app/4567

Look closely at the two lines. The public key (abc123def456) is identical. The project id (4567) is identical. The only thing that changed is the host — sentry.io became jentry.app. That is the entire migration: no SDK package swap, no new init() options, no diff in your instrumentation code, no relearning an API. You change one environment variable and ship.

Why this works: jentry is wire-compatible with the Sentry SDKs

"Sentry SDK compatible" isn't marketing shorthand here — it's a protocol statement. The official Sentry SDKs (sentry-javascript, sentry-python, sentry-go, sentry-java, sentry-ruby, sentry-php, and the rest) have no special knowledge of Sentry's servers baked in. They speak a documented HTTP protocol: they take your DSN, derive an ingest URL and an auth key from it, serialize your events into a specific format, and POST them. jentry implements the receiving end of that exact protocol. To the SDK, jentry is indistinguishable from any other endpoint that honors the contract.

Three pieces make up that contract, and jentry handles all three the way the SDKs expect.

1. The DSN tells the SDK where and how to authenticate

From the DSN, the SDK computes the ingest URL (host + project id) and pulls out the public key for auth. Repoint the host and the SDK simply computes a jentry URL instead of a Sentry one. Your jentry DSN — no code or SDK change. Nothing else in the SDK's behavior changes.

2. The X-Sentry-Auth header carries the key

On each request, the SDK attaches an auth header that looks like this:

X-Sentry-Auth: Sentry sentry_version=7,
  sentry_key=abc123def456,
  sentry_client=sentry.javascript.node/7.x

jentry parses that header, reads the sentry_key=… pair, and resolves it to your project — the same mechanism Sentry uses. (For browser SDKs that send the key as a sentry_key query parameter instead of a header, jentry reads that too, and its CORS responses explicitly allow the x-sentry-auth header so direct browser posts work.)

3. The envelope is the event format

Modern Sentry SDKs batch events using the "envelope" format: newline-delimited JSON that packs many items — errors, transactions, sessions — into a single request. Its shape is simple:

{ envelope header, may include the dsn }
{ item header: {"type":"event"} }
{ item payload: the error/event JSON }
{ item header: {"type":"transaction"} }
{ item payload: the transaction JSON }

jentry parses this envelope line by line, routes each item by its type, and runs it through the same ingest pipeline as a single event. Performance transactions, sessions, and errors all land correctly because they're all just items in the stream the SDK already produces.

Before and after: what actually differs

One row changes. Everything you wrote stays exactly as it is.

The practical implication for your team

Because the SDK and your instrumentation don't change, the migration is just a config + deploy, and it carries the properties you'd want from that:

• No code review of instrumentation changes — there are none. The only diff is the DSN value (ideally an env var), so your existing release process applies.
• Reversible in seconds. If you want to go back, point the host at Sentry again. No code to revert.
• Run both in parallel during evaluation. Stand up two projects, give half your services the jentry DSN, and compare the captured errors side by side before committing.
• Rate-limit signalling still works. When jentry needs you to back off, it returns Retry-After and X-Sentry-Rate-Limits — the same headers the SDKs already understand — so backpressure behaves exactly as before.

A 3-step migration

1. 1Create a project in jentry and copy its DSN (you'll notice it's the same shape you already know).
2. 2Replace the DSN your app uses. If your old key/project map cleanly, you can even keep the existing key and project id and just change the host — many setups change only that one segment.
3. 3Redeploy so the new DSN value is picked up, then trigger a test error and watch it appear in jentry.

That's the whole procedure. The reason it's this short is the reason this post exists: there is no SDK to swap and no instrumentation to redeploy — only a destination to repoint.

Honest caveats

Compatibility is about the ingest protocol, not about cloning every server-side behavior. A few honest notes so you know what to expect:

• Issue grouping is computed by jentry, so fingerprints and grouping can differ in edge cases from what Sentry produced — your historical issues don't carry over, and grouping starts fresh.
• jentry targets right-sized teams, not billions of events per month. If you outgrew self-hosted Sentry's ~50-container footprint or found hosted Sentry too pricey, that's exactly the gap jentry fills; if you genuinely need Sentry's largest-scale SaaS tier, be clear-eyed about that.
• Some newer or niche SDK item types may be ingested but not yet surfaced in the UI. Core errors, performance transactions, releases, and sessions are the well-trodden path.

None of those touch the migration mechanics. The switch itself is a one-line DSN change, and that's true precisely because jentry chose to be compatible at the wire — the envelope, the auth header, and the DSN — rather than ask you to adopt yet another SDK.