Sentry SDK compatibility

Trapify implements the Sentry ingest wire protocol. If your application is already instrumented with a Sentry SDK, you do not need to remove it, replace it, or touch a single line of application code. You change one environment variable.

Switch the DSN

Environment

# Before
SENTRY_DSN=https://abc123@o12345.ingest.sentry.io/67890

# After — same SDK, same code
SENTRY_DSN=https://<your-trapify-key>@trapify.tech/<project-id>

Redeploy. Your next unhandled exception appears in the Trapify dashboard, grouped into an issue, with the same stack trace and breadcrumbs your Sentry SDK was already collecting.

What is supported

The envelope endpoint (/api/<project-id>/envelope/) used by all current SDKs
The legacy store endpoint (/api/<project-id>/store/)
Exception events with full stack frames and in-app detection
Breadcrumbs, tags, level, environment, release, and user context
Rate-limit and quota responses (429 / 403 with Retry-After and X-Sentry-Rate-Limits), which Sentry SDKs honour by backing off automatically

What is not

Trapify is wire-compatible, not a Sentry re-implementation. Performance tracing, session replay, profiling, and cron monitoring are outside the error-tracking scope — events of those types are accepted and discarded rather than rejected, so an SDK configured for them will not error.

Why the project id is numeric

Sentry SDKs parse the DSN and reject a non-numeric project id before any network request is made. Trapify therefore derives a numeric project id from your DSN key and shows the full DSN, already assembled, in your project settings. Copy it as-is.

Migrating gradually

Because the switch is a single environment variable, the safest migration is per-environment: point staging at Trapify first, confirm the issues look right, then move production. Both services can run side by side during the overlap — nothing in the SDK is Trapify-specific.

Starting fresh instead? The quickstart uses the native Trapify SDK, which is smaller and has no Sentry dependency.