Data in transit
All traffic to the ingest API and all webhook delivery happen over TLS. Every
webhook is signed with HMAC-SHA256 using a per-subscriber secret
so your receiver can prove a request genuinely came from Everframe and was not
altered in flight. The signature and a timestamp travel in the
X-Everframe-Signature header (format t=<unix>,v1=<hex>),
and the timestamp lets you reject replayed requests. See
verifying webhooks for the exact algorithm.
Data at rest
SDK keys and webhook signing secrets are stored encrypted; SDK keys are looked up by a keyed hash rather than kept in plaintext. Report artifacts are served only for your plan's retention window, then permanently erased a further 14 days after that window ends. On the Free plan, attachments are also withheld (not erased) while the org is over its install limit.
Retention & data minimisation
Report artifacts — screenshots, recordings, logs, and the stored envelope — are served for your plan's retention window — 14 days on Free, 90 on Starter, 365 on Pro, and unlimited on Enterprise — so you can access and act on a report for as long as your plan provides it, not just long enough to hand it off. The floor under every window is delivery (retrying and dead-lettering a webhook takes about a week; even Free's window clears that with room to spare). A further 14 days after your plan's window ends, artifacts are permanently erased. You control what your SDK captures and can redact sensitive fields before submission, so the smallest useful payload is the one that leaves the device. Retention is not the only reason an attachment can stop being served: on the Free plan, screenshots, video, audio, and session replay are withheld — reversibly, nothing deleted — while the org is over its install limit. See data & retention.
Abuse & integrity controls
- SSRF protection. Webhook destinations are validated before delivery; requests to internal or disallowed network ranges are blocked.
- Rate limiting. The ingest API is rate-limited per SDK key and per source IP to absorb abuse without affecting healthy traffic.
- Payload limits. Uploads are size-capped and decompression is bounded to guard against malformed or hostile payloads.
- Idempotency. Duplicate submissions are de-duplicated so an SDK retry never fans out a report twice.
- Delivery circuit breaker. A receiver that fails repeatedly is automatically paused to protect both sides, with a clear reason you can see in the delivery log.
Reliable, signed delivery
Failed deliveries are retried on a backoff schedule across roughly four days before a report is dead-lettered, and every attempt carries a fresh delivery id and attempt counter so your receiver can reconcile exactly what happened.
Sub-processors & hosting
We run on a small set of vetted infrastructure providers (cloud hosting, object storage, email delivery, payment processing, and AI model inference), each bound by a data-processing agreement. A current list is available on request. We aim to process data within the European Economic Area; see our Privacy Policy for transfer safeguards.
Responsible disclosure
If you believe you’ve found a vulnerability, please email [email protected] with enough detail to reproduce it. We’ll acknowledge your report, investigate, and keep you updated. Please give us a reasonable chance to fix the issue before any public disclosure, and avoid accessing or modifying data that isn’t yours while testing.
Common questions
Do you use our bug reports to train AI models?
No, we do not train models on your data. Each of the following processes report contents, described on its own, without depending on the others. AI triage runs automatically on every report and sends report contents to a model-gateway sub-processor; its output is a severity suggestion, duplicate detection, and a summary — the AI triage toggle (Project Settings → AI triage) controls it. Resolution analysis runs automatically when a linked ticket enters a resolved column, and sends the ticket's title and description, its triage summary, and up to 20 recent thread messages from every report linked to it — including messages your end user wrote — to the same model-gateway sub-processor; its output is a short account of how the bug was resolved, stored for your team; the AI triage toggle controls it too. The AI assistant sends report contents, and can return attachment images and text into its context, to the same model-gateway sub-processor whenever someone in your organisation uses it on a report — the AI triage toggle does not control it. An AI agent run sends a linked ticket's title and description to the same model-gateway sub-processor whenever someone assigns the ticket to the AI agent — the AI triage toggle does not control it either. Separately, search and duplicate matching send short derived text — such as a triage summary, an error signature, a component name, a card's title and description, or a search query someone types — over a separate endpoint and credential from the model-gateway sub-processor above, which may be the same underlying vendor depending on configuration; the full report is never sent this way. We do not sell or share report contents.
Can I verify a webhook actually came from Everframe?
Yes. Recompute the HMAC-SHA256 of <timestamp>.<raw-body> with your signing secret and compare it, in constant time, to the v1 value in the signature header. Full code is in the webhooks guide.
Where is data stored, and for how long?
Within the EEA where possible, and only for your plan's artifact retention window (14 days to unlimited, depending on plan), plus a further 14-day grace period before permanent erasure. On the Free plan, attachments are also withheld while the org is over its install limit — reversibly, nothing deleted. See data & retention.
Do you offer a DPA?
Yes — email [email protected] to request our Data Processing Agreement.
Who operates Everframe?
Scriptx, UAB, a company registered in Lithuania (European Union). More about the company, or see the privacy policy for our controller and processor roles.