Overview - Crustdata Docs

This section maps every legacy endpoint to its replacement and points you at the migration guide that walks the change in detail. Each guide follows the same structure — request keys, identifier behavior, field mapping, type changes, removed features, added features, response shape, error responses, and a migration checklist — so once you have ported one endpoint, porting the next is mechanical.

If you are starting fresh and not porting an existing integration, skip this section and go straight to the Documentation or the API reference for the product you need.

Quick reference

Every legacy endpoint and the guide that walks the migration:

Domain	Legacy endpoint	Current endpoint	Migration guide
Company	`POST /screener/companydb/search`	`POST /company/search`	Company search
Company	`POST /screener/company/search`	`POST /company/professional_network/search/live`	Live company search
Company	`GET /screener/company`	`POST /company/enrich`	Company enrich
Person	`POST /screener/persondb/search`	`POST /person/search`	Person search
Person	`GET /screener/person/enrich`	`POST /person/enrich`	Person enrich
Person	`POST /screener/person/search`	`POST /person/professional_network/search/live`	Live person search
Person	`GET /screener/person/enrich?enrich_realtime=true`	`POST /person/professional_network/enrich/live`	Live person enrich
Job	`POST /data_lab/job_listings/Table/`	`POST /job/search`	Job search
Job	`POST /data_lab/job_listings/Table?sync_from_source=true`	`POST /job/professional_network/search/live`	Live job search
Web	`POST /screener/web-search`	`POST /web/search/live`	Web search
Web	`POST /screener/web-fetch`	`POST /web/enrich/live`	Web fetch
Social Post	`GET /screener/linkedin_posts`	`POST /social_post/professional_network/enrich/live`	Social posts
Social Post	`POST /screener/linkedin_posts/keyword_search`	`POST /social_post/professional_network/search/live`	Search social posts

What changes for every endpoint

Three changes apply to every migration. Apply them once across your client code, then follow the per-endpoint guide for the rest.

1. Authorization scheme

The legacy endpoints accepted Authorization: Token <key>. Every current endpoint uses Authorization: Bearer <key>.

- Authorization: Token YOUR_API_KEY
+ Authorization: Bearer YOUR_API_KEY

2. API version header

Every current endpoint requires x-api-version: 2025-11-01. Calls without it are rejected with 400.

x-api-version: 2025-11-01

3. Error envelope

Legacy 4xx and 5xx responses returned a free-form { "error": "..." } string. Every current endpoint (except 401, which still uses a flat { "message": "..." }) returns a structured envelope:

{
    "error": {
        "type": "invalid_request",
        "message": "Human-readable description.",
        "metadata": []
    }
}

Update your error handlers once — the new envelope is identical across every endpoint in this section.

Common shape changes

These show up in most migrations but not all. Use the per-endpoint guide for the exact details.

Change	Where it applies
`GET` query parameters → `POST` JSON body	All `GET /screener/*` and `GET /screener/.../enrich` endpoints became `POST`. Comma-separated query values became JSON arrays.
`filter_type` / `column` → `field`	Every search/live endpoint renamed the per-condition identifier key. Filter operator values (`in`, `not_in`, `=`, `(.)`, etc.) are unchanged.
Match-result envelope	Enrich endpoints now wrap results in `{ matched_on, match_type, matches: [{ confidence_score, person_data \| company_data }] }`.
Cursor pagination	Some search endpoints replaced numeric `offset` with opaque `cursor`. Pass `next_cursor` from the response as `cursor` on the next request.
Nested response sections	Flat top-level keys (`linkedin_`, `glassdoor.`, `g2.`, `crunchbase_`, etc.) moved under neutral sections (`basic_info`, `employee_reviews`, …).
`404` no-match → `200` empty matches	Many endpoints replaced `404` for no-results with `200` and an empty `matches: []` or `[]` array. Handle both during the transition.

Migration order

If you are porting a multi-endpoint integration, this order minimizes rework:

Update the HTTP plumbing once

Switch the Authorization scheme to Bearer, add the x-api-version: 2025-11-01 header, and update your error handler for the new error.type / error.message envelope. These three changes are identical for every endpoint, so make them in your shared client first.

Port enrich endpoints

Enrich calls are usually on the critical path (a single user lookup, often blocking). Start with Company enrich and Person enrich and update response parsers to handle the new matches[].company_data / matches[].person_data envelope.

Port search endpoints

Search calls usually drive batch jobs and dashboards. Rename column/filter_type to field, migrate field names per the mapping tables, and adopt cursor pagination where applicable. See Company search and Person search.

Port live (real-time) endpoints

Live endpoints replace the legacy enrich_realtime=true / sync_from_source=true flags. They are now distinct URLs — see the Live company search, Live person search, Live person enrich, Live job search, and Search social posts guides.

Port utility endpoints

Finally, port the cross-cutting utilities — Web search, Web fetch, and Social posts. These typically don’t share parsing code with the rest of your integration, so they can move at any point.

By domain

Company

Three migrations: indexed search, live search, and enrich.

Person

Four migrations: indexed search, indexed enrich, live search, and live enrich.

Job

Two migrations: indexed search and live search. The legacy generic dataset-query body is replaced by purpose-built endpoints with cursor pagination and structured aggregations.

Web

Two migrations: web search and web fetch. The legacy fetch_content=true mode is removed.

Social Post

Two migrations: per-entity enrich and keyword search.

Conventions used across guides

Every per-endpoint migration page follows the same template:

Section	What you’ll find
Header table	Path, method, auth, version, base URL — legacy vs current at a glance.
1. Request keys	Mapping of every legacy query parameter / body key to its current equivalent.
2. Identifier behavior	How many identifiers per call, supported types, mutual-exclusion rules.
3. Field-name mapping	Legacy field paths → current dot-paths, grouped by response section.
4. Type changes	Fields whose JSON type changed (e.g. `year_founded` string → integer).
5. Removed features	Legacy parameters or response sections that have no direct replacement, with workarounds.
6. Added features	New capabilities exposed on the current endpoint.
7. Response shape	Side-by-side legacy/current envelope examples.
8. Error responses	New error envelope and the cases that trigger each status code.
9. End-to-end example	A `curl` invocation against each endpoint with equivalent inputs.
Migration checklist	A copy-pasteable bullet list of every change required to port the endpoint.

If a section is missing on a particular guide, that aspect of the API is unchanged for that endpoint.

Need help?

If a field you depend on isn’t listed in the mapping table or the checklist doesn’t cover your use case, email support@crustdata.co with the legacy request you were making and the field you can’t find — we will point you at the right replacement.

Documentation Index

​Quick reference

​What changes for every endpoint

​1. Authorization scheme

​2. API version header

​3. Error envelope

​Common shape changes

​Migration order

​By domain

Company

Person

Job

Web

Social Post

​Conventions used across guides

​Need help?

Quick reference

What changes for every endpoint

1. Authorization scheme

2. API version header

3. Error envelope

Common shape changes

Migration order

By domain

Conventions used across guides

Need help?