The API, answered in full.

You create it yourself, in the Entity Bind workspace you create online. Create your workspace online and verify your email; it starts on the Free plan with no card. Create your workspace online at https://app.entitybind.com/app?signup=1 and verify your email. Once you are signed in, you create, list and revoke your own keys, each scoped to your tenant with read or resolve permission, and each raw key is shown once. Paid plans are available through Stripe in workspace Billing; registry checks follow your active plan. The evaluation opens at a separately agreed activation date. The planned 1,000-credit evaluation runs at full research depth and is separate from the shallow Free plan. Keys are stored as SHA-256 digests. A read key reads what your tenant already holds and cannot resolve; a resolve key runs the data plane; review and admin credentials carry separate scopes. In your workspace, rotating a key is create, switch, revoke; the admin API's rotate endpoint adds a grace window, and an exposed key can be revoked.

A golden record, assembled field by field from whichever source has the best claim to each field — survivorship — with per-field provenance, a calibrated `match_confidence` and the basis behind it, a ranked candidate list, a `decision_id` receipt, the pipeline version, a `usage` block, and a set of flags that say what actually happened: `replayed`, `depth_capped`, `entity_created`, `escalation_unavailable`, `no_identifying_signal`, `more_input_needed`. Every field of the golden record carries its source id, source URL, retrieval time, licence, first-seen and last-checked timestamps, a confirmation count and an age in days, and the entity reports the age of its stalest field rather than its freshest — because one recently confirmed value should not be able to make a stale record look current.

`/v1/resolve` takes one record and binds it to an entity in your catalogue, or abstains. It persists: it mints a record id, may create or join an entity, and writes a decision receipt you can reopen. `/v1/match` is a stateless pairwise comparison of two records you supply — is this the same company as that one — and it persists nothing at all, so there is no record id, no entity id and no receipt to fetch afterwards. Both charge on the same rule. Use match when you are adjudicating somebody else's proposed pair and do not want a catalogue entry; use resolve when you want a golden record and an audit trail.

Yes, over `/v1/batch`, which takes up to 500 records per request by default, is `Idempotency-Key` aware, writes one ledger row per outcome rather than one summed row, and is order-independent within the batch. Your Entity Bind workspace also takes a CSV upload, up to 500 company rows by default, and a finished run downloads as CSV or JSON with its decision receipts. For a larger file in a Sprint, the import we run streams it through the same public API — so a successful import is evidence your own integration will work rather than a bespoke pipeline — and carries your key column through as `client_ref`, so the output joins back on your ids rather than ours. It is not a queue: batches go one at a time, and a 300,000-row file is an overnight run. Plan the window rather than the throughput.

With the `depth` parameter, which is a price and latency ceiling and can be set per record even inside a batch. `research` is the default and runs the whole cascade. `adjudication` stops before agentic research. `probabilistic` is a hard no-egress setting enforced in code at both egress points: no model provider and no registry, so a capped record reaches neither. There is a second, orthogonal control, `enrich=false`, which turns the registries off at any depth for a caller whose contract forbids the lookup. Capping never lowers precision — the alternative to a deep answer is an abstention rather than a cheap guess — so what you trade away is automation rather than correctness.

Yes, and it is the trap worth knowing about before you read a resolution rate. The effective depth is the lower of what you requested and what your plan permits, so a `research` request on the Free plan executes at the no-egress stage instead — and because a new Entity Bind workspace starts on that plan, and because the clamp applies even when usage quota enforcement is off, a whole run can execute two stages shallower than the one it was quoted at. What stops that being invisible: `/v1/batch` echoes a `depth_ceiling`, the import we run for a Sprint keeps the shallowest value any batch reported and prints both on its run report, and resuming a run at a different depth is refused rather than blended. Read the ceiling before you read the rate.

Per endpoint class, and bucketed per tenant rather than per key, so a customer with three keys has bought one allowance. The published defaults are 1,000 reads a minute, 300 resolves, 300 matches, 30 batches and 120 review calls, scaled by a plan multiplier. `RateLimit-Limit`, `RateLimit-Remaining` and `RateLimit-Reset` come back on success as well as on a 429, and a `Retry-After` is added when a request is refused. Two caveats worth reading before you size anything: the limits are deployment settings you should read from `GET /v1/reference/limits` rather than hard-code, and without a shared limiter store they are enforced once per replica.

One envelope on every failure — `{"error": {"code", "message", "correlation_id"}}` — with a stable machine code from a published vocabulary you can fetch at `GET /v1/reference/error-codes`. Internal detail never reaches a caller: any 5xx message is replaced with canned text, so a driver error cannot leak SQL or bound parameters. Two choices are worth knowing. A wrong-tenant id returns 404 rather than 403, because a 403 confirms the id exists and turns every read into an enumeration oracle. And `deadline_exceeded` is a 504 rather than a 503, because nothing upstream is down — our budget for that request ran out, and the fix is a lower depth or a longer allowance.

In two different ways. `/v1/batch` takes an `Idempotency-Key` header: identical concurrent callers wait for and replay the sealed winner, the same key with different content is a permanent conflict, and row ids are derived deterministically so a replay mints the same ids. `/v1/resolve` needs no header, because its idempotency is a content fingerprint — the SHA-256 of the submitted record excluding the server-minted id — computed before the cascade runs. A byte-identical resubmission returns the same binding, is flagged `replayed`, and costs nothing. The binding has no expiry. It is per tenant and per exact content: one corrected postcode is a different fingerprint and a fresh resolution.

Yes, within a deliberately narrow boundary. `POST /v1/entities/{id}/detach` moves exactly one attributed record, and every fact carrying that record's origin id, onto a fresh entity, in one transaction that also updates both of the indexes deciding which candidates get compared, the replay binding, your own crosswalk links and an immutable receipt. It requires a review-scoped credential, so an ingestion key cannot do it, and it fails closed with a 409 before any write if any of six preconditions does not hold. What it is not is a general unmerge: no arbitrary cluster split, no bridge analysis, no rollback to a historical cluster shape, no automatic reattach. Registry and research facts stay on the source rather than being guessed onto one side.