Skip to main content
The Knock2 REST API gives you programmatic access to everything the Knock2 platform identifies and enriches — company accounts that visit your website, individual contacts, ICP scoring data, CRM field mappings, and more. Every resource is available over HTTPS, returns JSON, and follows predictable, resource-oriented URL conventions. Whether you’re pulling identified accounts into your CRM, triggering outbound sequences, or building custom dashboards, this reference covers every endpoint, parameter, and response field you need.

Base URL

All API requests are made to the following base URL:
Every endpoint is prefixed with the API version, so a complete URL looks like:

Authentication

The Knock2 API uses Bearer token authentication. Include your API key in the Authorization header of every request:
Requests without a valid API key return a 401 Unauthorized response. You can generate and manage your API keys from the Knock2 dashboard.
See the Authentication guide for full details on key scopes, rotation, and security best practices.

Versioning

The current API version is v1. All endpoints are prefixed with /v1/. When breaking changes are introduced, a new version prefix will be released and the previous version will be supported for a deprecation window. Non-breaking additions — new optional fields, new optional request parameters — may be added to the current version at any time.

Pagination

List endpoints return cursor-based paginated results. Cursor-based pagination is more stable than offset pagination when records are being added in real time — you won’t miss records or see duplicates as you page through results. Request parameters Response envelope Every paginated response includes:
See the Pagination guide for a complete walkthrough with code examples.

Rate Limits

The API enforces rate limits to ensure fair use and platform stability. When you exceed the limit, the API returns a 429 Too Many Requests response with error code rate_limit_exceeded. Best practices for handling rate limits:
  • Implement exponential backoff — after a 429, wait before retrying, and double the wait time on each subsequent 429.
  • Respect the X-RateLimit-Reset header (a Unix timestamp for when the current window resets) rather than a fixed delay. There is no Retry-After header.
  • Avoid tight polling loops; prefer webhooks or reasonable polling intervals (30 seconds or more).

Error Format

All error responses use a consistent envelope:
  • code — A machine-readable string you can use to handle specific error cases programmatically.
  • message — A human-readable description of what went wrong.
  • details — Optional structured information about the error (for example, per-field validation errors). null when not applicable.
Common error codes

Available Endpoints

Accounts

Contacts

Filter Sets

There is no GET /v1/filter-sets/{filter_set_id} endpoint — filter sets can only be retrieved via the list endpoint.

Webhooks

There is no GET /v1/webhooks/{webhook_id} or PUT /v1/webhooks/{webhook_id} endpoint — subscriptions can only be listed in bulk, created, or deleted.

Auth

Activity

Scores

Enrichment

Tenants (multi-tenant partners only)

A parent key can also read one direct child tenant’s account/contact/activity/score data without switching keys — see Reading a Child Tenant’s Data.

Tracking Script