Everything a partner may do is written on their key: one query, the columns it hashes, how often, from where and until when. Every call is held to it, and the rest of your schema stays out of reach. Their API documentation lists the one endpoint they can call.
1endpoint in their OpenAPI
16 hexfor an email, hashed
60 minof overlap when you rotate
The partner
The governed core
Your database
The key's termseverything the partner may do, on one key
Identify the key its secret, still active, not expired, from an allowed addressApply its limits 60 a minute, on top of the server's own401429 rate_limited
02 · Policy
Check the grant this one saved query, on its own connection; no other query, no schema, no SQLValidate parameters status is typed and bound403
03 · Execution
Run it the SQL fixes Acme's partner idMask it customers.email hashed, traced through aliases and expressionsRecord it history lists what was masked
Stablecompatibility promiseExpmay change in a minor releaseA leaked secret? Rotate it: the old one keeps working for an hour by default while the partner switches.
The partnerAcme's backend, with one keyTheir API docs list one endpoint; a leaked copy of the key used from anywhere else fails like a wrong key.
↓
The key's termsOne query · email hashed · 60/minute · their network · until 2027-01-01Everything the partner may do, written on the key.
↓
The governed coreIdentity → policy → executionThe key is identified and limited, its grant allows one saved query and no schema, and the email column is hashed wherever the SQL puts it.
↓
Your databaseTwo tables behind one queryThe rest of the schema isn't reachable with this key.
↓
What Acme gets backTheir rows, email hashedEqual values give equal codes, so they can still join on it. Rate-limit headers tell them how much is left.
whokey partner-acmedoorGET /q/acme_ordersone query, no schema ✓email hashed ✓60/min · IP list · expiry ✓dataacme_orders · their rows only
For a partner or customer
Hand a partner one query, not your schema
A customer wants their orders. The usual answer is a bespoke endpoint, an auth middleware and a quarter of review time. The alternative is a scoped key that can call exactly one saved query, written for their rows.
✓A queries grant names saved queries; it reaches nothing else on the connection, not even the schema.
✓Masking rules on the key hash or hide columns like email, whatever the SQL calls them. Partners who sign in through your identity provider can share one query instead: a from_claim parameter takes customer_id from their token, never from the request.
✓Rate limit, IP allow-list and expiry on the key. Rotate its secret with a grace period when it leaks.
✓Their /openapi.json lists only the one endpoint they can call. Put it in a collection and they get a Postman collection too.
The example APIs ship with a generated database and one scoped key per scenario, so you can try each of these in a few minutes without connecting anything of your own.