Skip to main content
Check what Keenable receives and logs when you send a request, before you route production traffic through it. The Privacy Policy and the Terms of Service are the binding documents. This page says how they apply to API traffic and adds what you can observe as a caller. For a short statement of what Keenable keeps from your requests, see Data and privacy.

Request logs

Keenable logs and stores every search and fetch request on the default data policy, whether or not you send an API key. Don’t send secrets or personal data in a query, a URL or a prompt. The log for a request includes:
  • The search query, or the fetched URL, any fetch prompt, and the results.
  • Your IP address and your user agent.
  • The X-Keenable-Title value, if you send one. The keyless /public paths require it.
  • The request ID that the response returns in X-Request-Id. Support uses it to find your request (see Get help).
  • If you send an API key: your organization and the ID of the key.
Keyless requests are logged the same way as keyed ones. See Try it without a key.

Retention and use

Neither the Privacy Policy nor the Terms of Service sets a fixed retention period for request logs. SELECT also stores the output of each query as a result set that later queries can read. See Result sets.

Zero data retention

Zero data retention (ZDR) is a data retention policy that Keenable sets for an organization. It is part of the Enterprise offer, and the console has no switch for it. To ask for ZDR, open Talk to us in the console and choose Zero data retention, or use the contact form. Confirm with Keenable what the policy covers for your traffic, and ask for it in your contract. As a caller in a ZDR organization, you see two things:
  • The policy follows the API key. Keenable takes the policy from the organization that owns the key. No header or parameter sets it. A request with no credential, such as a call to a /public path, isn’t under your organization’s policy. Send a key from the ZDR organization on every call.
  • Some requests return 400. The API refuses a request that the policy doesn’t allow, and retrying the same request returns the same 400.

API keys

  • The console shows the full API key once, when you create it. Copy it then. Afterward the key list shows only the start of the key.
  • API keys belong to your organization and never expire on their own.
  • You can revoke an API key in the console at any time. If you send a revoked key, the API returns 403.
  • Keep the key out of your code. The SDKs, the CLI and the MCP server read it from the KEENABLE_API_KEY environment variable.
If a key leaks, create a new key, update KEENABLE_API_KEY everywhere it is set, then revoke the old key. See Key lifetime and rotation.

Encryption in transit

Every Keenable address is an HTTPS URL: the API and the MCP server at https://api.keenable.ai, SELECT at https://select.keenable.ai and the console at https://app.keenable.ai. Call the https:// URLs as documented, so your API key and queries are encrypted on the way to Keenable.

Payment details

Stripe processes card payments. Under the Privacy Policy, Keenable receives limited billing information, such as the billing name, the billing address and the last four digits of the card. Keenable doesn’t store full card numbers.

Report a vulnerability

Email security@keenable.ai with:
  • The affected URL, endpoint or service.
  • What the vulnerability is and its security impact.
  • Steps to reproduce it. A minimal proof of concept is enough.
The vulnerability disclosure policy covers services under keenable.ai and its subdomains. Under that policy, Keenable acknowledges a report within 3 business days and asks for coordinated disclosure, 30 days by default. Keenable runs no formal bug bounty program. The policy also lists what is out of scope and the safe harbor terms. For a problem that isn’t a vulnerability, see Get help.