Klairr connects to Stripe with a restricted API key, never a secret key. Restricted keys can be scoped to specific resources and to read-only — Klairr only ever needs read.
Step 1: Create a restricted key
In your Stripe Dashboard:
- Go to Developers → API keys
- Click Create restricted key
- Name it “Klairr (read-only)”
- Grant Read on:
- Customers
- Subscriptions
- Invoices
- Charges
- Payouts
- Leave every other resource at None
- Click Create key and copy the
rk_live_…value
Klairr rejects secret keys (sk_…) outright; only restricted keys are accepted.
Step 2: Add the connector
| Field | Example |
|---|---|
| Restricted API key | rk_live_… |
| Mode | Live (production data) |
Klairr verifies the key by attempting a read (customers.list(limit: 1)) and an over-permission probe — a synthetic delete that any read-only key rejects. Keys that succeed at the delete are over-permissioned and rejected at setup.
What Klairr queries
The connector exposes five canonical tables: customers, subscriptions, invoices, charges, payouts. The LLM emits a small JSON DSL:
{ "list": "subscriptions", "filters": { "status": "active" }, "limit": 100 }
Filter keys are allow-listed (created, customer, subscription, status, collection_method, arrival_date). No write or admin verbs exist in the DSL grammar.
Privacy
Stripe records contain customer PII (names, emails, billing addresses). Klairr applies a 1-hour query-result cache TTL by default for Stripe data and excludes row-level values from long-term AI Memory — only metric/column shapes are persisted across conversations.
Notes
- Test mode (
rk_test_…) is fully supported — useful for design-partner trials before connecting production data. - Stripe API version is pinned to
2026-04-22.dahlia; upgrades are scheduled with the team. - Stripe paginates lists; the connector handles pagination up to the configured maxRows cap.