Privacy

1. What the service records

Email address. Minting an API key at POST /v1/keys requires a valid email address. It is stored on the account together with a normalized form of it (lowercased, any +tag removed, and for Gmail addresses the dots removed). The normalized form is the identity used to hand out the one-time free starter credit once per address. The no-signup trial makes market-data calls without an account or an email address at all.

API keys. Only a peppered hash of a key is stored. The key itself is shown once, when it is minted, and is not written to logs or kept in readable form anywhere. A lost key cannot be re-sent; the recovery flow issues a new one.

Request logs. Each request is recorded with its path, HTTP method, response status, response time, the account it belonged to (for authenticated calls), the requesting IP address, a coarse client classification, and the User-Agent string (truncated). For market-data calls the requested ticker and timeframe are stored. An acquisition-funnel step is stored for the pages that have one. For requests over MCP, the log keeps the JSON-RPC method, the tool name of a tools/call, and the client name and version the client declares in its handshake — and nothing else from the MCP payload.

Signup fingerprint. At key signup a peppered hash of the signup IP address is stored on the account. The raw signup address is not kept. The hash exists only so the operator can count how many keys came from one origin when looking for signup abuse; it is used for reporting and never blocks a signup by itself.

Internal IP list. The operator's own IP addresses are recorded in a separate list so that internal testing traffic can be excluded from the product's own usage analytics.

Newsletter consent. Newsletter opt-in is off by default; only an explicit opt-in is counted. When you do opt in, consent is recorded as timestamps on the account: when the box was ticked, when a double-opt-in link confirmed it, and if applicable when you later unsubscribed.

Subscription and payment status. For paying accounts the account row holds the plan, its status, the included allowance, the period end, and the Stripe customer and subscription identifiers. The credit balance and the per-call charges are held in separate ledger tables.

2. What is deliberately not stored or logged

• Card details. Card entry happens on Stripe's hosted pages. patternfetch does not receive, see, or store card numbers.
• MCP call arguments. The tickers and timeframes you pass over MCP are not recorded — only the method and, for a tool call, the tool name are kept.
• Crypto payment payloads. For x402 USDC top-ups the payment authorization, its signature and nonce are never copied into logs; the logging path copies out only an allowlist of non-secret fields.
• Request bodies, headers and query strings are not written to error logs. The query string in particular can carry an email-confirmation or key-recovery token, so only the request path is recorded. Any credential shape that does reach a log line — API keys, Stripe keys, bearer tokens, database passwords, long hex signatures — is redacted before the line is written.
• Confirmation and recovery links. Only a peppered hash of each token is stored. The raw token is mailed and then dropped; it is never logged or persisted in readable form.

3. Third parties

Stripe (card payments and subscriptions). patternfetch creates a Checkout or billing-portal session and passes Stripe only the internal account identifier as metadata, the amount, and the product name. Stripe hosts the checkout and the billing portal and collects the payment — and any billing details you enter there — itself. Stripe returns a customer identifier, and for a subscription a subscription identifier, which are stored on the account so the portal and later events can find it.

Resend (transactional email), used only when a mail provider is configured; otherwise an SMTP fallback is used, and if neither is configured no mail is sent. The provider receives the recipient address, subject and body of a message — today the signup-confirmation mail and the newsletter double-opt-in. When no provider is configured the full starter credit is granted immediately instead of being staged behind a link that could not be delivered.

Yahoo (US stocks and ETFs) and Binance (crypto-asset spot pairs) are the market-data sources. They receive the ticker symbol being looked up so they can return the data. They do not receive an account, an email address, or a key — only the symbol.

Coinbase (x402 USDC top-ups). A USDC payment on the Base network settles through Coinbase's CDP facilitator, which verifies the on-chain authorization. It handles the on-chain payment, not a patternfetch profile; the public payer wallet address and the transaction hash may be recorded against the top-up. Testnet payments settle through the public x402.org facilitator instead.

4. Keeping, changing and removing data

Newsletter mail carries an unsubscribe link, and unsubscribing is self-service: the link carries a signed token, so it needs no login and leaves a recorded unsubscribe timestamp.

An API key can be rotated through the recovery flow. Rotating a key deactivates the previous key on that account.

There is no automated self-service route that deletes an account or erases its stored data; the system does not do that on its own today. Request logs, account rows and payment records remain until removed by hand.

See also the Terms of Service and the Disclaimer.