Security & Trust

Every workspace is a separate tenant. Links, QR codes, scan events, conversions and settings are scoped to a workspace at the query layer on every read and write, so one workspace can never see another's data. Client sub-workspaces created under an agency are isolated the same way.

All traffic is served over HTTPS/TLS. Data at rest is encrypted by our infrastructure providers (Prisma-managed PostgreSQL and Netlify).

Different credentials need different handling, so we describe each one rather than making a single blanket claim:

• Link passwords are stored as scrypt hashes with a unique random salt per password. We cannot recover them, and they are never logged.
• API keys are generated by us as high-entropy random tokens and stored as a SHA-256 digest — the plaintext token is shown once at creation and never again. Because the token is random rather than user-chosen, the digest is not salted: there is no dictionary to attack. If you lose a key, revoke it and issue a new one.
• Webhook signing secrets cannot be hashed — signing each delivery with HMAC SHA-256 requires the original secret — so they are encrypted at rest instead, with AES-256-GCM. The key lives in our application environment rather than the database, so a database dump on its own yields no usable signing material, and the secret is decrypted in memory only at the moment a delivery is signed. This is application-managed encryption, not an HSM or external KMS. It is redacted from workspace data exports. Treat it as a shared secret, rotate it if you suspect exposure, and always verify the x-reroute-signature header rather than trusting the payload alone.

Accounts are authenticated by the application itself: sessions and password hashes live in our own database, never with a third-party identity service. Sensitive actions — issuing or revoking API keys, managing webhooks, changing member roles, and deleting a workspace — are gated to workspace owners and admins. API access uses per-workspace bearer tokens.

Security-relevant actions — role changes, credential lifecycle, domain changes, data exports, billing changes and link deletions — are written to an append-only, tenant-scoped audit trail that owners and admins can review in the dashboard.

Scan IP addresses are anonymized at write time (IPv4 truncated to /24, IPv6 to /48). Workspace owners and admins can export all of a workspace's data as JSON at any time — with credential material redacted — and can permanently delete a workspace, which removes its data across our systems. Owners can set an optional scan-data retention window; once set, a scheduled job enforces it daily by deleting scan events older than the window, and owners can also run the purge on demand. The default is to keep scan data until you remove it. See our Privacy Policy for details.

Public endpoints — shortlink resolution, the GS1 resolver, authentication and the API — are rate limited with a distributed limiter so limits hold across our serverless infrastructure. Redirect destinations and outbound webhook targets are validated to block requests to internal/private network ranges (SSRF), and user-supplied content in interstitials is escaped to prevent injection.

Report an abusive destination behind an rrte.link shortlink to loading.... Our takedown policy describes how we review reports. We do not promise a response time. Printed QR codes are not paused; staff may remove the destination behind a 200 page. Takedown is per destination, not for the rrte.link host.

Billing is handled by Stripe. We never see or store full card numbers; card data is processed directly by Stripe.

We hold no third-party security certifications today: we are not SOC 2 audited, and we do not claim to be. We are happy to walk prospective customers through our current security posture under NDA, and this page will be updated when that changes. What we plan next is below.

SAML 2.0 single sign-on against your own identity provider — Okta, Microsoft Entra ID, Google Workspace, or any SAML IdP — is included in the Enterprise plan, self-serve, with SCIM directory sync for Okta and Entra ID. Setup guides live at /docs/sso.

A SOC 2 Type II attestation is on our roadmap. We do not claim an audit is underway today. The practices such an audit covers are already in production and described on this page: encryption at rest for secrets (see How we store each credential), tenant isolation, audit logging, and IP anonymization (see Data protection & privacy).

For procurement and vendor reviews, our Customer Trust Pack collects the tenancy model, encryption, authentication, logging, subprocessors, data controls, and incident contact in one place.

If you believe you've found a security vulnerability, please report it privately to loading... before any public disclosure. We appreciate reports and will respond promptly.

Researchers can also discover this contact via our security.txt (RFC 9116) at /.well-known/security.txt.