X-TKN Privacy Policy

Last Updated: October 14, 2026

This policy explains what Fennec LLC does with personal data in X-TKN, the one-time secret and token API at api.x-tkn.com and x-tkn.com.

It does not cover the Fennec Studio print-on-demand storefronts. Each of those stores publishes its own privacy policy at its own domain.

1. Two different roles, and why the distinction matters

X-TKN puts us in two positions at once, and almost every question about your rights depends on which one applies.

For account data, we are the controller. We decide what to collect from you when you sign up, bill, and support your account. That is our decision and our responsibility.

For what you put through the API, we are a processor acting on your instructions. You choose what goes in a payload, what reference identifiers you attach, and who you send a link to. If that content includes someone's personal data, you are the controller of it and we process it only to deliver the service.

The practical consequence: if you are an end user whose data was put through X-TKN by a company you deal with, we are not the right party to ask. Ask them. We will help them respond, but we cannot identify you in our records, and for encrypted payloads we cannot read the data at all.

2. What we collect as controller

2.1 Account data

  • Email address, and the Firebase identifier for your sign-in.

  • Any name or contact detail you add to your profile.

  • Your plan, quota usage counters, and historical usage records.

  • Trial status and dates, and whether a payment method is on file.

  • Marketing preferences.

  • The people you invite to your account: their email address, sign-in identifier, role, invitation status, and dates.

  • What you configure for your recipients: a tenant subdomain, custom retrieval domains, and branding, including a logo you upload.

  • A record of changes to your account, such as plan changes, and of any legal hold placed on it.

2.2 Billing data

Payments run through Stripe. We store the Stripe customer and subscription identifiers, subscription status, price, renewal date, and cancellation state. We never receive or store your card number. Card details go to Stripe directly and are governed by Stripe's privacy policy.

2.3 API keys

We store a hash of each API key, never the key itself, together with a truncated display form, the description you give it, which member of your account created it, creation date, last-used timestamp, and any IP allowlist you configure.

2.4 Anti-abuse data at sign-in

Asking for a sign-in link by email, which is how an account is created with an email address, runs a reCAPTCHA Enterprise assessment through Google and a check of the email domain against a list of disposable-mailbox providers. The contact form runs the same reCAPTCHA assessment. Signing in with Google or Apple runs neither check. Forwarding aliases such as iCloud Hide My Email, SimpleLogin, and Firefox Relay are deliberately not blocked. We record the outcome of these checks, not the underlying assessment detail.

2.5 Technical logs

Our servers and network edge record request metadata: timestamps, paths, status codes, source IP addresses, and user agents. This is what lets us investigate outages and abuse.

3. What we process on your behalf

We hold the following only because you instructed us to, and only for as long as the service or your plan requires.

Payloads. Stored as you send them, and every payload must arrive encrypted: as the published xtkn.v1 envelope, or as ciphertext from your own scheme under xtkn.v1r. We hold ciphertext and no key, and the API refuses a payload that is not an envelope. A secret created in the console is encrypted in your browser before it is sent. We check an envelope's shape, not its contents, so readable data you wrap in a v1r envelope yourself is stored as you sent it.

Reference identifiers. The refId you attach to a token, which is often your own user identifier. We do not interpret it.

Token metadata. Type, description, expiry, use limits, and lifecycle timestamps.

Recipient email addresses. Only where you use emailed recipient authentication. We use the address to send a numeric challenge code and for nothing else.

Recipient IP addresses. Where a recipient reveals a secret, or tries to and fails, we record the source IP on the audit row for your account, so your audit trail can answer who read what and from where. Opening the link without revealing records nothing.

Destinations you configure. Webhook endpoint URLs, audit stream destinations, and their delivery records.

We never write a token code or a payload into an audit record. The audit trail is the thing most likely to be exported to a CSV or streamed into your bucket, which makes it the worst possible place to keep a secret.

4. If you received a secret from someone

You did not sign up for anything, and you are reading this because someone sent you a link.

When you open a retrieval link:

  • Your browser fetches the encrypted secret. Where the sender used browser-side encryption, the decryption key sits in the part of the URL after the #, which browsers never send to a server. We do not receive it and cannot decrypt the secret.

  • When you reveal the secret, or try to and fail, we record when and the source IP address on the sender's audit trail.

  • If the sender required email verification, we send a numeric code to the address they specified and hold that address until the secret is resolved.

  • The retrieval page sets no cookies, and requests from it are sent without credentials.

The sender is the controller of the secret and of your address if they supplied one. Direct access and deletion requests to them.

5. How we use data

  • Operating the API and delivering secrets — Performance of our contract with the account holder

  • Billing, collection, and dunning — Performance of contract

  • Quota accounting and the overage emails — Performance of contract

  • Fraud, abuse, and security investigation — Legitimate interest in keeping the service usable

  • Product and service email — Performance of contract

  • Marketing email — Consent, withdrawable at any time

  • Meeting legal and tax obligations — Legal obligation

We do not sell personal data. We do not use payloads to train models, and for encrypted content we could not.

6. Who else sees data

We use a small set of subprocessors, listed with their purpose and location in the Subprocessor List. We will publish changes to that list before a new subprocessor starts processing.

We also disclose data where the law requires it, in response to a valid court order or government request, and where we believe disclosure is needed to prevent harm. Where we are permitted to tell you about such a request, we will.

Note what a legal demand can and cannot reach. We can produce account records, token metadata, and audit rows. We cannot produce the plaintext of an encrypted payload, for a court or for anyone else, because we have never held the key.

If we are acquired or merge, data transfers with the business, and we will give notice.

7. Where data is held

Our infrastructure runs in Amazon Web Services in the United States. The API, its database, file storage, and outbound email run in the us-west-2 region (Oregon). The website's pages are served from storage in us-east-1 through Amazon's global content delivery network. If you are outside the United States, using the service means your data is transferred there.

For customers in the European Economic Area, the United Kingdom, or Switzerland, transfers are made under the European Commission's Standard Contractual Clauses, which are part of our Data Processing Addendum. Request one at support@fennec.studio.

Region-pinned storage is not available today. If that is a requirement, tell us before you rely on the service.

8. How long we keep things

  • Audit events — Developer 7 days, Team 90 days, Enterprise 365 days, then deleted. Where we have agreed a longer retention period with you in writing, that period applies instead

  • Expired, revoked, or exhausted tokens — At least 30 days after they finish. Currently deleted after 60 days of inactivity

  • Active tokens — Until they expire, are used up, are revoked, or you delete them

  • Sandbox accounts and their contents — 24 hours from creation, then deleted

  • Account and billing records — Until you delete the account, then deleted, except where tax law requires us to keep transaction records for seven years

  • Webhook delivery records — No automatic retention window is applied today, and deleting an endpoint does not delete its delivery records. Ask us to delete them

  • Technical logs — Rotated on our infrastructure provider's schedule

Deleting a token or an account removes the record from the production database rather than hiding it, and it cannot be undone. The one exception is legal hold: where a preservation obligation, court order, or active claim applies, we suspend deletion of the affected records until it ends, then delete them.

9. Security

  • All traffic uses HTTPS.

  • Token codes are 256-bit values from a cryptographic random source, stored as SHA-256 hashes. There is nothing in our database to brute-force offline.

  • API keys are stored as hashes, and can be pinned to source IP ranges on Team and above.

  • Where you use the published envelope format, payloads are encrypted with AES-256-GCM using a 256-bit key we never receive.

  • One-time retrieval is decided in a single conditional database update, so exactly one read succeeds even under concurrent attempts.

  • Anti-abuse rate limiting runs in a firewall in front of the API, per source IP and per API key.

Two honest limits. Browser-side encryption on a page we serve means you are trusting us not to serve key-capturing code on that page load; that is a smaller and more auditable surface than trusting our database, and it is not nothing. And no system is perfectly secure, so we do not claim ours is.

We hold no security certification today. We do not claim SOC 2 or ISO 27001, and you should treat any such claim not published by us as false.

10. Your rights

Where you hold an account with us, you can ask us to:

  • Give you a copy of your account data, in a portable format.

  • Correct data that is wrong.

  • Delete your account and its contents.

  • Stop sending marketing email, which you can also do from any marketing email.

  • Restrict or object to processing based on legitimate interest.

Write to support@fennec.studio, with "Privacy" at the start of the subject. We will respond within thirty days and will ask enough to confirm you are who you say you are. We will not charge for a reasonable request.

If you are in California, the CCPA and CPRA give you rights to know, delete, correct, and opt out of sale or sharing. We do not sell or share personal information as those terms are defined, and we will not discriminate against you for exercising a right.

If you are in the EEA, the UK, or Switzerland, the GDPR gives you the rights above plus the right to lodge a complaint with your supervisory authority. Where we act as processor, the account holder who sent us your data is your controller and the first place to ask.

11. Cookies and browser storage

The retrieval page at `x-tkn.com/s/` sets no cookies, loads no analytics, and calls nothing but our own API. This is deliberate and structural rather than a setting: that page is served by a layout that carries no tags at all, because anything loading third-party script there could reach the decryption key in the URL fragment.

Elsewhere on x-tkn.com:

  • The account console keeps you signed in using browser storage managed by Firebase Authentication. Clearing it signs you out.

  • A consent banner records your choice in your browser's local storage. It is not a cookie and it is not sent to us.

  • We count page views ourselves. Each page sends our API its path, the page you came from, and a random session identifier kept in local storage, which is replaced after 30 minutes of inactivity. The count is not linked to your account and goes to no one else.

  • If you arrive through a link carrying campaign parameters (utm_*, gclid, fbclid), the page keeps them in session storage for that visit. They are not sent to us.

  • Most pages load their fonts from Google Fonts, so Google receives your IP address and browser details when one of them loads. The retrieval page does not.

  • The sign-in and contact forms load Google's reCAPTCHA Enterprise, which may set Google's own cookie.

No third-party analytics or advertising tag is configured on `x-tkn.com` today, so none loads. The page-view count above is our own. Our platform supports third-party tags, and if we ever enable one here it will load only after you consent through that banner, and we will update this section before it goes live.

12. Children

X-TKN is a developer product and is not directed at children. We do not knowingly collect data from anyone under 18. If we learn we have, we delete it.

13. Changes

We will post changes here with a new date. For material changes we will email account holders at least thirty days before they take effect.

14. Contact

Fennec LLC

Write to support@fennec.studio for privacy requests, DPA copies, security reports and anything else. Starting the subject with "Privacy", "Security" or "Legal" helps us route it.