Security

Last updated August 9, 2026

We hold two things worth protecting: your customers' home addresses, and a balance that can be spent on posting things. This page is what we actually do about that, written plainly enough to forward to whoever asks you for it.

The account

  • Sign-in is passwordless — a one-time code by email, or Google. There is no password for us to lose or for you to reuse.
  • Sessions are cookie-based, HTTP-only, and scoped to our domain.
  • Roles are owner, admin and member. Only owners and admins can mint API keys, connect AI assistants or change billing.

Keys, tokens and secrets

  • API keys are shown once and stored as a SHA-256 hash. We cannot show you an existing key because we do not have it — a lost key is replaced, never recovered.
  • Comparisons are constant-time, so a wrong key leaks nothing by how long it took to reject.
  • AI assistant tokens expire hourly and their refresh tokens rotate on every use; reusing a spent one is treated as theft and kills the connection.
  • Every key is scoped. A key that only sends cards cannot read your address book.
  • Card payment details never reach us. Stripe handles them; our worker runs on a restricted key that cannot read a full card number.

Keeping customers apart

Every query that touches your data is filtered by your organization before it runs, and the filter is applied at the layer that talks to the database rather than in the screen that renders it. Row-level security is on across the customer tables as a second lock. An API key, a webhook and an AI assistant connection are each tied to exactly one organization and cannot be pointed at another.

In transit and at rest

  • HTTPS everywhere, with HSTS. There is no plaintext route into the service.
  • Data at rest is encrypted by our database and storage providers.
  • Outbound webhooks are signed with HMAC-SHA256 so your system can prove a payload came from us.

AI assistant connections

Connecting Claude, ChatGPT or Gemini uses OAuth 2.1 with PKCE. The assistant never sees your sign-in. Tokens are bound to this server and refused anywhere else; consent is recorded per application, so approving one does not approve another; sending a card is flagged as irreversible so a compliant assistant must ask you first; and the ability to register a webhook is deliberately not offered to assistants at all.

The longer version, including what an assistant can and cannot see, is at /docs/ai/security.

The physical side

  • Cards are written and packed in our own facility by our own staff. Fulfilment is not subcontracted.
  • Address data reaches the machines as a print job for one batch and is not retained on them.
  • Misprints and spoiled cards are shredded, not binned.

What we are honest about not having yet

We are a small company. We do not hold SOC 2 or ISO 27001, and we would rather say so than imply otherwise. We do not run a paid bug bounty. There is no formal on-call rota outside working hours, though in practice someone looks. If your procurement process needs any of those, talk to us — knowing what is actually being asked for is how it gets built.

Reporting a vulnerability

Email security@scribblecards.com with enough detail to reproduce it. We will acknowledge within two working days and tell you what we are doing. We will not take legal action against anyone who reports a problem in good faith, does not access data beyond what is needed to demonstrate it, and gives us a reasonable chance to fix it before going public.

If we ever suffer a breach affecting your data, we will tell you what happened, what was affected and what we are doing — within 72 hours of confirming it, whether or not the law requires it in your jurisdiction.