Security & data handling

Error tracking means sending production exceptions — sometimes including user data — to someone else's servers. You should know precisely what that means before you do it. This page says what Trapify stores, where, for how long, and who can read it. Where something is not yet in place, it says that too.

What we store

An event is written exactly as your SDK sends it. Nothing is enriched, inferred or purchased from anywhere else. These are all the fields persisted per event:

• message — The error message or the text you passed to captureMessage. May contain personal data.
• level — fatal, error, warning, info or debug.
• platform — The runtime that produced the event, e.g. javascript or node.
• environment — Whatever you set in init — production, staging, and so on.
• release — The release identifier you set in init.
• exception — Exception type and value, plus every stack frame: filename, function, lineno, colno, contextLine and the in-app flag. contextLine is a line of your source code. May contain personal data.
• breadcrumbs — The trail leading up to the error — console output, fetch calls and navigation events, each with a timestamp, category, message and level. May contain personal data.
• request — The request URL, the HTTP method, and any headers your SDK chose to attach. URLs frequently carry identifiers in the path or query string. May contain personal data.
• user — id, email and username as passed to setUser, plus ipAddress when a Sentry-compatible SDK includes one. The Trapify SDK never collects an IP address, and Trapify derives none of these server-side — every value here was sent deliberately by the client. May contain personal data.
• tags — The string key/value pairs you attach with setTag. May contain personal data.
• timestamp — When the event occurred.

Alongside events we store your account details (email address and display name, held by Firebase Authentication), your organisation and project records, and an audit log of triage actions — who resolved or ignored which issue, and when.

What we do not do

• Trapify performs no server-side PII scrubbing. What your SDK sends is what gets stored. Scrubbing happens on your side, before the event leaves your process, via the beforeSend hook — return a modified event to send it, or null to drop it entirely. See the SDK reference.
• We do not sell, share or rent your data, and we run no third-party analytics on it.
• We do not use your error data to train machine-learning models.
• We do not read your events except when you ask us to help debug something.

Where it is stored

Events are stored in Google Cloud Firestore in the eur3 multi-region, which is Europe — Belgium and the Netherlands. Firestore replicates data across that multi-region automatically; there is no separate scheduled backup or point-in-time-recovery configuration beyond that today, and we would rather say so than imply a backup regime we have not set up.

One caveat, stated plainly because omitting it would make this page misleading: the ingest function itself currently runs in us-central1 (Iowa, United States). Event payloads therefore transit US compute before being written to European storage. Moving ingest compute into Europe is on the roadmap. If US transit is disqualifying for you today, Trapify is not yet the right fit, and we would rather you knew that now.

How long it is kept

The retention policy is 30 days of event history on Free and 90 days on Pro. Issues — the grouped, deduplicated records — are kept for the life of the project.

Automatic deletion is not yet enforced. There is no scheduled purge job running today, which means events may currently be retained beyond the stated window. In the meantime, deletion on request is honoured — see below — and the purge job is being built. We would rather publish this gap than let you assume a guarantee the system does not yet make.

Deleting your data

Self-service deletion does not exist yet. The dashboard today has no button that deletes a project, an organisation or an account, so every deletion is handled by us on request. For anything at all — a project and its issues and events, a specific user's events, an export of your data, or your account and organisation entirely — email support@trapify.tech from the address on the account. We act on deletion requests within 30 days and confirm in writing when it is done.

Who has access

Trapify is operated by one person. Production data access is limited to that operator, through Google Cloud IAM on the trapify-tech project — there are no shared logins and no contractors with database access. In the application itself, access is scoped by organisation membership and enforced by Firestore security rules: events and issues are readable only by members of the owning organisation, and no client can create or modify an event at all. Only the ingest function, running with admin credentials, writes events.

Abuse and availability controls

Ingest is protected by a per-DSN rate limit and a hard monthly event quota per plan. Exceeding either returns 429 or 403 with Retry-After and X-Sentry-Rate-Limits, which Sentry-compatible SDKs honour by backing off. Quotas are hard caps: exceeding one drops events rather than generating an invoice you did not agree to.

Sub-processors

• Google Cloud / Firebase — hosting, Firestore storage, authentication and serverless compute.
• Paystack — subscription billing and payment processing. Trapify never sees or stores card details.

Reporting a vulnerability

Email security@trapify.tech. Include steps to reproduce and what you were able to access. You will get an acknowledgement within 72 hours and an assessment with a fix timeline after that.

Please do not test against other people's data, run automated scanning against ingest, or publicly disclose before we have had a chance to fix the issue. Report in good faith and we will not pursue you.

What we do not claim

Trapify is early software run by a small operation. There is no SOC 2 report, no ISO 27001 certification, no penetration test and no signed DPA template yet. This page will be updated when any of that changes. Everything above describes what is true today, not what is intended.