For architects and CTOs
Security and operations
How the service behaves when you depend on it: limits, failure, keys, where your data goes and who processes it. What exists today is marked live. What an enterprise buyer will ask for and we have not built yet is marked coming soon, rather than left for procurement to find.
This page describes how the service behaves, not how the index is built: serving topology and index internals are not published. The line is what a caller can observe or a customer can verify.
Limits and failure
What happens under load and when something goes wrong, stated as a caller sees it.
One rate limit per account, in credits per minute
LiveCounted once for the whole account across every key, not per machine. Every response carries x-ratelimit-limit and x-ratelimit-remaining; a 429 carries a retry-after with the real seconds until the window turns over.
Bounded concurrency, and a 503 at capacity
LiveAn account has a bounded number of requests in flight; past it, a 429 with retry-after. When the service is saturated it answers 503 at once with a retry-after, rather than queueing the request until it times out. A request that runs past 45 seconds is answered 408.
Failure is explicit, and priced as such
LiveA call that runs and fails costs one credit, never more than the call itself; a refused call (401, 402, 429) costs nothing. Every keyed response reports what it charged in x-credits-charged. A result missing part of the index says partial and is never presented as complete.
Status page and incident history
Coming soonA public status page with component health and a written record of every incident.
The contract
How you know what the API does, and how you will hear when that changes.
A machine-readable contract generated from the server
LiveOpenAPI 3.1 at /openapi.json and the MCP tool definitions at /mcp/tools.json are produced by the running server from the same definitions it serves, and the API fails its own build if the two disagree. /describe publishes the live filter vocabulary, credit costs and ground contract.
Deterministic statuses
Liveground decides sufficient, insufficient, stale, partial or empty by a fixed rule, with no model in the call. The same request over the same corpus gives the same status.
Versioning and deprecation policy
Coming soonA written policy for breaking changes with a notice period. Today changes are additive and recorded in the changelog, and deprecated fields are marked in the OpenAPI document, but there is no versioned path and no committed notice period.
Request IDs and trace propagation
Coming soonA request id on every response, and W3C traceparent accepted and echoed, so a call can be traced across your stack and ours in a support case.
Keys and access
Who can call the API on your account, and who can change it.
Keys stored only as a hash
LiveAPI keys are prefixed ulb_ so secret scanners recognise them. We keep a one-way hash and the last four characters, never the key; a lost key is replaced, not recovered.
Labelled keys, rotated in one step
LiveIssue as many labelled keys as you need. Rotation is a single transaction, so there is never a moment with two live keys or none, and any key can be revoked from the console.
Console roles: owner, admin, member
LiveMembers see usage and credits; admins also manage keys and view billing; owners also change the plan and spending and manage the team. Checked on the server for every change. Sign-in is by single-use emailed link, with no password to leak.
Consequential console actions are logged
LiveKey issue, rotation and revocation, plan and billing changes, membership changes — and every view of your organisation by our own staff — are written to an audit log with the actor and address.
Scoped keys
Coming soonKeys restricted to named endpoints or to read-only operations. Today a key can call every endpoint on its account.
SSO for the console
Coming soonSAML and OIDC single sign-on, so console access follows your identity provider.
Your audit log, visible and exportable
Coming soonThe console audit log readable by your owners and admins, and exportable to your own systems.
Your data
What we keep, for how long, and where it is processed.
Query analytics keep a fingerprint, not the text
LiveThe analytics we keep to run the index record a salted one-way fingerprint of a query and its shape, not the query text, and not joined to your key. Treat the queries you send as disclosed to us all the same: they cross our service to be answered.
TLS only, and nothing cached in between
LiveThe API is served over TLS with HSTS. Keyed responses are marked no-store so no proxy or browser cache keeps them, and every response carries no-referrer and nosniff. Cross-origin browser calls are not enabled, so a key cannot be used from a web page.
Served from the EU
LiveThe API and the console run in Germany (Hetzner, Nuremberg). The public-web index is built in the United States (AWS, us-east-1) from crawled public pages; your queries and account data are not sent there.
Named subprocessors
LiveHetzner (hosting, Germany) · Amazon Web Services (index build and transactional email for sign-in links, United States) · Stripe (payments; card details go to Stripe, never to us).
Published retention windows
Coming soonFixed retention for query analytics and usage records, enforced by a running job and stated here in days. The windows are defined; enforcement in production is not yet switched on, so we do not quote them as a promise.
A choice of region
Coming soonA second serving region, and a choice of where your traffic is processed. Today there is one region, in the EU.
Encryption-at-rest statement
Coming soonA published statement, and the controls behind it, for every store that holds customer data.
Backup and disaster recovery
Coming soonStated recovery-point and recovery-time objectives for account and billing data, with the restore tested.
Commitments and assurance
What we promise contractually and what an auditor has checked. Today, less than an enterprise buyer will want — said here rather than discovered in procurement.
An SLA
Coming soonA contractual availability commitment with service credits, on committed plans. The published plans carry no uptime guarantee today, and the terms say so.
Support response targets
Coming soonResponse targets by plan. Today support is by email, answered by the people who build the service, with no stated target.
A data processing agreement
Coming soonA standard DPA, with notice before a subprocessor is added or changed.
Independent security attestation
Coming soonAn independent audit of our controls, starting with SOC 2 Type I. None has been carried out yet.
Vendor risk, stated plainly
unlob is small, self-funded and founder-led. That cuts both ways. There is no valuation the price has to grow into and no investor who needs the product repositioned — and there are fewer people than at a venture-funded competitor, so continuity is a fair question to ask. We would rather answer it here than have it come up in diligence.
What limits the risk today:
- Nothing proprietary to remove. unlob is one HTTP call and a standard MCP server. There is no SDK or client library to unpick, and the evidence and receipts you received are yours to keep.
- No upstream to lose. We crawl and serve our own index, so no second supplier can reprice, deprecate or rate-limit the service underneath you. Seewhy an own index matters.
- Margin, not subsidy. The price is positive-margin at every tier, so it does not depend on the next round. See the cost model.
- Inside your boundary, by engagement. For a buyer who cannot accept a hosted dependency at all, the sovereign edition is the same closed product deployed where you control it — scoped per engagement, and in development.
What does not exist yet is on this page as coming soon. If one of those items decides whether you can adopt unlob, tell us which — it is how we order the roadmap.
Frequently asked questions
Where is the unlob API hosted?
In Germany: the API and the console run at Hetzner in Nuremberg. The public-web index is built in the United States on AWS from crawled public pages; customer queries and account data are not sent there. There is one serving region today; a choice of region is on the roadmap.
Does unlob store the queries I send?
The query analytics we keep to run the index record a salted one-way fingerprint and the shape of a query, not its text, and not joined to your key. Queries still cross our service to be answered, so treat them as disclosed to us. The sovereign edition is the answer for a buyer who cannot accept that.
Is there an SLA?
Not yet. The published plans carry no contractual uptime guarantee, and the terms say so. An SLA on committed plans, a status page and support response targets are on the roadmap and marked as coming on this page.
Can API keys be restricted to specific endpoints?
Not yet: a key can call every endpoint on its account. Scoped keys are on the roadmap. Today you can issue separate labelled keys per workload, rotate them in one step and revoke any of them from the console.
What happens to my integration if unlob goes away?
There is little to unpick: unlob is one HTTP call and a standard MCP server, with no SDK or proprietary client to remove, and the evidence and receipts you received are yours. We are small and self-funded, and we would rather say that plainly than have you discover it in diligence.
Evaluate it against your checklist
Start on the free tier to test the behaviour described here, or write to us with the controls your organisation needs.