~/logosyncer

Security

You are pointing a third-party service at your Stripe account, and your customers’ brands end up on your website. Both deserve a clear explanation of how the system is built. This page is the human-readable version; the same rules are stated for machines in /llms-full.txt.

Read-only, structurally

LogoSyncer can never move money or write to your Stripe account, because it never holds a credential capable of either. There are exactly two ways to connect, and both are read-only:

  • OAuth connect requests read-only access and is revocable from your Stripe dashboard at any time.
  • Restricted-key connect accepts only restricted keys (rk_live_) with exactly four read scopes — Customers, Subscriptions, Events, Account — and nothing else. Full secret keys (sk_) are rejected outright, as is any key carrying write permissions. The exact click-path for creating such a key is in the quickstart.

The publish gate — why there’s a confirmation code

Publishing a wall is the one action in the system that is externally visible the moment it happens: it announces “these companies are our customers” on the open web, and you cannot un-see something that was served. So a wall serves publicly only when all of these hold:

  • your signup email is verified, and
  • the Stripe connection is proven — either via OAuth (which itself proves account control), or via a confirmation code we email to the connected Stripe account’s own address, and
  • the connection is live-mode (test-mode data never serves publicly).

The Stripe-inbox code exists for one reason: leaked restricted keys are common (committed to repos, left in CI logs). Verifying just an email address would let whoever found a leaked key publish a company’s customer list from a throwaway inbox. The Stripe account’s own inbox is the one thing a leaked-key attacker doesn’t control — and for the legitimate owner it’s just one more paste. Until the gate holds, the public wall URL returns a bare 404 that doesn’t even confirm the wall exists; the authed GET /v1/walls tells you exactly what’s missing.

There’s also a panic button — POST /v1/unpublish_all or one click in the dashboard — that 404s every wall on the account immediately, with a hard cache purge.

Domains, never emails

The sync engine reads only the email field of your Stripe customers, extracts the company domain (jane@acme.com → acme.com), and discards the address in-request. What we store is the domain — never your customers’ email addresses, and never customer names (display names come from the logo provider’s brand data, not from Stripe). Freemail addresses (gmail.com and friends) are filtered out entirely. Full details in the privacy policy.

Who controls the wall — and reporting a listing

LogoSyncer is a sync layer, not a publisher. You decide which companies appear on your site: the exclusion list and per-wall pin/hide are yours, and they apply at serve time from our database, so they never wait on a Stripe sync — cached copies expire within minutes. In data-protection terms Kraftscale GmbH (the Swiss company that operates LogoSyncer) acts as your processor for subscriber-domain data and you are the controller; the split is set out in the privacy policy.

A company that spots its logo on a wall can report it at logosyncer.com/takedown — no account needed. Reports are forwarded to the account holder who controls that wall, since they hold the controls. We suppress an asset across the service where we are legally required to (court order, valid trademark or IP complaint, applicable law) or where a listing breaches the terms. We offer no fixed response time and no removal guarantee. The reporting URL ships in every wall’s JSON (meta.takedown_url) and on the free-tier badge, so the path is reachable from every rendered wall.

Encryption at rest

Stripe credentials are encrypted with AES-256-GCM before they touch the database, with key versioning for online rotation and the ciphertext bound to its owning account (so rows can’t be swapped between accounts). Credentials are ciphertext before they ever reach a backup; backups are themselves envelope-encrypted with a separate key held outside the hosting account. Keys are never logged, and error reporting scrubs anything key-shaped before it leaves the server.

The embed on your site

The embed script runs inside your production pages, so it’s built accordingly: about 5KB gzipped, zero dependencies, a closed Shadow DOM, no HTML injection (all content is created via DOM APIs with text nodes), no cookies and no storage. Every URL the script itself requests is on the LogoSyncer origin: the wall JSON, plus a small same-origin render beacon (the wall’s public id and the preset name — no visitor identifiers).

One disclosure worth being precise about: logo images are served from /logo/{domain} on our origin, and that URL currently redirects to our logo provider’s image CDN (img.logo.dev). So your visitors’ browsers do make one request to that CDN per logo. No cookies are sent and no LogoSyncer identifier is attached, but the CDN does see the request the way any third-party image host would. If you need every byte on your own origin, proxy /logo/ through your CDN.

Reporting

LogoSyncer is operated by Kraftscale GmbH, a limited liability company incorporated in Switzerland. Security contact: abuse@logosyncer.com. To report a logo you have seen on a wall, use /takedown — it’s tracked, and it reaches the person who can act on it.