One pipeline, reached from your warehouse, your CRM or your editor. 3 configure today. 3 you build.
- clients configured with one JSON object
- 3
- patterns over the same HTTP API
- 3
- routes into one pipeline, one page each
- 6
- rows written back to your CRM, warehouse or MDM
- 0
Shipped integrations
Configure the client, and the server answers. There is nothing to install and nothing to build, and a resolve from your editor is the same resolve as an HTTP call — the same cascade, the same confidence floor, the same credit rule and the same rate-limit bucket.
Claude Code
A shipped integration: Claude Code reads MCP servers from a JSON object with an `mcpServers` key, so the block below — a URL and a token presented unchanged on every request, in an Authorization header — is the whole configuration.
Eleven tools in the session: resolve_company, match_records, get_entity, get_crosswalk, get_enrichment_fields, search_entities, get_decision, get_usage, and the three review-queue tools.
Read itClaude Desktop
A shipped integration with two routes, and which one is right depends on who is installing it.
The same eleven tools, the same pipeline and the same credit rule as every other surface.
Read itCursor
A shipped integration: Cursor reads MCP servers from a JSON file in the same `mcpServers` shape every other client uses, at project scope inside the repository or at user scope for every project at once.
The eleven tools inside the editor, so a company identity question is answered where the code that depends on the answer is being written.
Read itPatterns over the HTTP API
The same endpoints, from a warehouse, a CRM or a Python process. Each page sets out the shape of the integration you would build: what leaves your system, what comes back, and what goes wrong at each step. Knowing that shape before you start is most of the work. No package, no managed application, no marketplace listing and nothing to install.
Snowflake
This is an integration pattern over the HTTP API, not a shipped connector.
Deduplication stated in your own identifiers: rows are grouped by the entity they landed on and labelled with your key values, so the answer is "these six of your rows are one company", in the ids your warehouse already uses.
Read itSalesforce
This is an integration pattern over the HTTP API, not a shipped connector.
Duplicate accounts identified in your own record ids, with a receipt per decision that reopens at a URL.
Read itPython
This is an integration pattern over the HTTP API, not a shipped connector.
A plain JSON API with a published schema and no client library between you and it, so a change in the payload is visible in your code rather than absorbed by a wrapper.
Read itOne JSON object, and the tools are in the session
The whole configuration for Claude Code, Claude Desktop and Cursor. Point the client at your deployment, present the key you create in your Entity Bind workspace in an Authorization header, and the 3 shipped routes are done.
{
"mcpServers": {
"entitybind": {
"type": "http",
"url": "https://host.example.com/mcp",
"headers": {
"Authorization": "Bearer rk_YOUR_KEY_HERE"
}
}
}
}host.example.com is a placeholder. The hostname comes with your workspace, and a client pointed at the placeholder will not connect.
A resolve from your editor is the same resolve as an HTTP call: the same stages, the same confidence floor, the same credit rule, the same rate-limit bucket, the same tenancy. Every resolve carries a decision id that reopens the whole evidence trail at a URL, so an agent’s answer is still checkable after the session has closed.
Put one thing in the agent’s own instructions before it calls anything: an abstention is an answer. It comes back with a ranked shortlist, a typed reason, the column that would have settled the record and a review id, and it costs nothing.
A pattern is not a connector
Snowflake, Salesforce and Python reach the same endpoints as everything above, and you write the code. Each page sets out what leaves your system, what comes back and what goes wrong at each step, so you can size the work before you open an editor.
This is an integration pattern over the HTTP API, not a shipped connector. There is no package, no managed application, no marketplace listing and nothing to install: what is described below is the shape of the integration you would build, written down because knowing the shape in advance is most of the work.
No package, no connector, no managed application and no marketplace listing exists for any of the 6 routes on this page.
How you get a key
Create your Entity Bind workspace online and verify your email. It starts on Free with 300 credits and no card. Create your own read or resolve keys, each shown once and revocable. Use https://app.entitybind.com as the hosted base URL. Paid subscriptions are purchased through Stripe in workspace Billing, with applicable VAT and no automatic usage or overage charges; registry checks follow your activated plan.
The full-pipeline evaluation is arranged separately and is not activated by signup. Request it for your workspace; we confirm availability, sources and the start date before activation. It starts with a conversation about your file.
If you are scoping one of the 3 patterns, create your Free workspace and inspect the company CSV you would have batched anyway. Create your own API key there; contact us if you need help choosing an integration shape.
Start freeTeams putting a company check beside a master they have to defend: a warehouse table behind an MDM, a CRM after a migration or a merger, a supplier file before a payment run, or an agent about to act on a counterparty.
Anyone who needs an installable connector with a vendor security review behind it. There is none here, on either shelf. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.
Every route names its own limits on its own page — the tool catalogue is readable without a credential, rate limits are per tenant across every surface at once, and one OAuth discovery gap stops a discovery-driven client ever starting its flow. The retention, erasure and tenancy detail a security review asks for is on the trust page, with where assurance stands: no SOC 2, no external validation of the accuracy figures, no customer holdout. Trust and security →
Once the client is talking to the API
Wiring is the easy half. Three families answer what goes in the request, what the request can reach, and whether this is the job you are actually doing.
- What to put in the requestWhich of the identifier columns already in your file settle a match on their own, who issues each one, the exact shape a value takes, and what goes wrong with it.Open
- What a wired client can reachThe registers a request can reach today, the licence instrument each publishes under, what may be stored rather than only returned, and the coverage this product does not have.Open
- Whether this is the job you are wiring forThe jobs this gets bought for, what breaks in each one today, and what the wrong merge costs to unwind once it has been made.Open
See it on your own rows first.
Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration.
300 credits. No card.
For a guided review of your file, explore the Merge Safety Sprint →
One question from each route
The first question each of the 6 integration pages has to settle.
Is the MCP server the same product as the API?
The same product and the same code path. The MCP surface delegates to the same application services the versioned HTTP routes do, so a resolve over MCP is the same resolve: the same cascade — the stages a record walks through, settling at the cheap deterministic checks where the identifiers allow it and reaching model work only where they do not — the same confidence floor, the same evidence, the same credit rule and the same rate-limit bucket. What differs is who is on the other end. The credential's plan caps depth before the cascade runs, so a key pinned to the probabilistic stage cannot reach agentic research by choosing this surface. It abstains instead.
Do I need OAuth to use the MCP server?
No. Try the static bearer path first: the rk_ key you create in your Entity Bind workspace is the whole credential, presented unchanged in an Authorization header on every request. A hosted MCP server is widely assumed to require OAuth, which makes a working bearer path read as broken unless somebody says otherwise. OAuth exists for the consumer-shaped install, where somebody pastes a URL into a client and will not paste an API key into a dialog. Both end up in the same place — an OAuth access token is verified by the same code path as an API key.
Can I use the same key in Cursor and in my application?
You can, and there is one thing to know before you do. Rate limits are bucketed per tenant rather than per key, because a limit a customer can multiply by minting a second key is not a limit — so an editor agent and a production job share one per-minute budget rather than getting one each. Separate keys are still worth creating in your workspace for a different reason: the ledger records the key id on every row, so two keys give you two readable columns in a usage export.
Is there a Snowflake connector?
No. There is no native application, no external function template, no Marketplace listing and no data share. What exists is a documented HTTP API with a batch endpoint that takes 500 records a request and echoes your own key on every row — enough to build the integration in a working day, if your account is permitted to make outbound calls. Scope it as build time on your side rather than as something to install.
Will Entity Bind merge our Salesforce accounts for us?
No. We tell you which of your rows are the same company, which of your existing matches we would not have made, and which we could not decide — in your own record ids, with a reopenable receipt for each. Merging is an irreversible write in your system, and the party that proposed a merge should not be the party that performs it. That separation runs inside the product too: the credential that approves a merge is not the credential that proposed it.
Is there a Python SDK?
No, and none is planned until there are enough integrations running to keep one current. The API is JSON over HTTPS with a bearer token and a published schema; a wrapper would add a dependency, a version skew and a layer that hides payload changes from you, in exchange for saving about thirty lines. If you want a typed client, generate one from the schema — with the caveat that the OAuth endpoints are excluded from it on purpose, so a generated client must never call them.