# Privacy and data retention

> SerpKite never logs your query text. Results are cached for a few hours under a hashed key, and usage records hold metadata only for 31 days. Here is exactly what is kept, where and for how long.

## The short version

- **Query text is never logged.** Not in application logs, not in usage records, not in the request log you see in the dashboard.
- **Usage records are metadata only** (endpoint, status, credits, latency, cache hit, which key) and are deleted after **31 days**.
- **Results are cached briefly** (up to 6 hours by default, 30 minutes for news, 1 hour for web pages and 24 hours for autocomplete) under a hash of the request, and batch results are kept for 24 hours so you can fetch them. Nothing else is kept.
- **API keys, session tokens and sign-in codes are stored as hashes**, never in plain text.

This page describes how the service is built. The binding terms are in the [Privacy Policy](https://serpkite.com/legal/privacy) and the [DPA](https://serpkite.com/legal/dpa).

## What we store, and for how long

| Data | Contains query text? | Retention |
| --- | --- | --- |
| Usage events (per request) | No. Endpoint, HTTP status, credits, latency, cache hit, batch flag, error code, API key ID, time | 31 days, then deleted |
| Request log and CSV export in the dashboard | No. Built from usage events | 31 days |
| Daily usage totals and the credit ledger | No. Credits per day, purchases, grants, refunds | Life of the account (needed for billing) |
| Result cache (read with [`max_age`](https://serpkite.com/docs/caching)) | The key is a SHA-256 hash of the normalised request, never the query text. The value is the result, with no account or key attached. Every successful live result is written, whether or not you send `max_age` | In memory only, expires automatically: up to 6 hours by default, 30 minutes for news, 1 hour for web pages and 24 hours for autocomplete |
| Batch job request | Yes, until the job runs | Cleared as soon as the job is processed |
| Batch job result | Yes (it is the SERP) | 24 hours, then deleted |
| Webhook deliveries | Sent to your URL; we keep only the delivery status | With the job |
| Application and database logs | No. Never API keys, cookies, `q`, webhook URLs or database query parameters | Short operational retention |
| Account data | Email, name, avatar, linked OAuth providers, team membership, settings | Until you delete the account |
| Payments | Handled by Paddle, our merchant of record. We store order IDs, pack, amount and credits, not card data | Until you delete the account; Paddle keeps invoices as tax law requires |
| Database backups | Account, billing and usage tables (encrypted) | 30 days |

Query text is never written to a log or a usage record. The only copies of results are the short-lived ones listed above: cache entries, which deduplicate identical requests and are served only to callers that send `max_age`, and batch results you haven't fetched yet.

## What we don't do

- We don't log the `q` parameter, API keys or cookies.
- We don't keep results after the retention windows above, and we don't keep a searchable archive of queries.
- We don't scrape anything behind a login. SerpKite fetches the public, logged-out Google results page through proxy networks. See [How we collect data](https://serpkite.com/legal/how-we-collect).

## Choosing the privacy trade-off

- **Don't want a cached copy served to you?** Don't send `max_age` (or send `0`). Every call is then a live fetch and `X-Cache` is `MISS`. The fresh result is still written to the cache for the windows above; `max_age` only controls reads.
- **Don't want batch results held?** Use realtime calls. Batch results always expire after 24 hours, whether you use a [webhook](https://serpkite.com/docs/webhooks) or fetch them.
- **Sensitive queries?** Realtime calls leave metadata in usage records (which endpoint was called, when, by which key, and what it cost) and a cache entry under a one-way hash that expires within hours. Raw HTML (`include_html`) is never cached.

## Secrets

- **API keys** are stored as SHA-256 hashes. The full key is shown once when created or rotated. See [API keys](https://serpkite.com/docs/api-keys).
- **Dashboard sessions** and **sign-in links and codes** are stored as hashes too. You can see and revoke your sessions from the dashboard.
- **Webhook signing secrets** are shown once; the dashboard shows only their prefix afterwards.

## Product analytics

The website and dashboard use privacy-friendly product analytics (PostHog, EU region) to understand which features are used, **only after you accept analytics cookies** in the cookie banner. Global Privacy Control and Do Not Track count as a refusal. You can change your choice any time under "Cookie settings" in the website footer or Settings → Cookies in the dashboard (see the [Cookie Policy](https://serpkite.com/legal/cookies)). API requests themselves are not sent to analytics. Query strings are stripped from every URL before an event is sent, so playground queries never reach analytics.

## Deleting your data

The account owner can delete the account from the dashboard settings. This removes the account, its API keys, remaining credits, ledger, usage events, settings and team, and signs out every session. Copies in encrypted backups roll off within 30 days. Invoices are kept by Paddle, our merchant of record, as tax law requires.

For data requests or questions, email privacy@serpkite.com.

## Compliance

- Data processing terms: [DPA](https://serpkite.com/legal/dpa).
- Who processes data for us: [Subprocessors](https://serpkite.com/legal/subprocessors).
- Security practices and how to report a vulnerability: [Security](https://serpkite.com/security).
- **SOC 2:** planned, not yet certified.

## Related

- [Caching](https://serpkite.com/docs/caching): How max_age and the result cache work.
- [Batch requests](https://serpkite.com/docs/batch): Queued jobs and their 24-hour results.
- [API keys](https://serpkite.com/docs/api-keys): Hashed storage, rotation and revocation.
- [Privacy Policy](https://serpkite.com/legal/privacy): The binding terms.