Skip to main content
Every record in Clustr has a Clustr ID: a person, an account, an opportunity, a competitor, a tag, a job and so on. It starts with a short prefix that says what kind of record it is, followed by 26 characters:
Use the Clustr ID whenever you need to point at a record: in a URL, in a request body, in a filter, or as the key you store in your own systems. A record keeps the same Clustr ID for its whole life, so it stays valid when someone renames their LinkedIn profile or a company changes its LinkedIn page.

​
Where you find it

Every object the API returns carries its Clustr ID in a field that starts with clustr_:
The same goes for the records an object points at: an opportunity in the search results carries clustr_opportunity_id, and the connector and prospect inside it each carry their own clustr_person_id. A list of ids, such as tag_ids, has its Clustr IDs in the same order in clustr_tag_ids. The MCP server answers with the same fields, so an assistant can pass a Clustr ID from one tool to the next.

​
Using it in requests

Every route that takes the id of a record also takes its Clustr ID, in the path, in a query parameter or in the body:
If you already store other ids, such as LinkedIn identifiers or the ids in our earlier responses, they keep working. You can move to Clustr IDs at your own pace. When you send the Clustr ID of the wrong kind of record (a tag’s id where a competitor’s is expected), the answer is 404.

​
Merged records

When Clustr finds that two records are the same person or the same company, it merges them. The Clustr ID of the record that was merged away keeps working: the answer is the surviving record, with its own Clustr ID and a redirected_from field holding the id you asked for. Update your copy to the new id when you see one.

​
Prefixes

Treat a Clustr ID as an opaque string: compare it as a whole, and read the prefix only to tell what kind of record it names.