Skip to main content
The Slant public API lets you read and manage CRM records (households, people, tasks, meetings, and more) from outside the app.

​
Base URL

​
Authentication

Every request must include an Authorization header using the Bearer scheme:
Tokens are issued from the API connections settings page on the API tab. Personal access tokens are read-only by default. To enable write access for a token, click Enable write access from the API token row and explain how you plan to use it. Write access is enabled immediately. Use /v1/me to check whether the current token can write.

​
Quickstart

Verify your token with a request to /v1/me, which returns the currently authenticated user:

​
Rate limits

Every request is checked against three buckets. The strictest bucket wins, and exceeded requests return 429 Too Many Requests.

​
Idempotency

Safely retry POST and PATCH requests by including an Idempotency-Key header with a unique value (a UUID works well):
A repeated request with the same key and body returns the cached response instead of creating a duplicate. Keys live for 1 hour by default and are scoped per endpoint — the same key on a different path creates a fresh record. 5xx responses are never cached, so retries after a server error always re-execute.

​
Request format

Requests with a body (POST, PUT, PATCH) must include Content-Type: application/json. Without it, the body is ignored and your fields come through empty. A malformed JSON body returns 400 invalid_json.

​
Conventions

  • Pagination — list endpoints accept page (default 1) and per_page (default 25, max 100). Responses include { data: [...], pagination: { current_page, total_pages, total_count, per_page } }.
  • IDs — all IDs are opaque strings. Use them as-is.
  • Book scoping — most endpoints accept an optional book_id query parameter. A “book” is an advisor’s workspace. Use GET /v1/books to list the books your token can see.
  • Request bodies — write endpoints use unwrapped JSON objects unless a specific endpoint says otherwise. Notes are a wrapped-body exception.
  • PATCH fields — PATCH endpoints document their own request fields. Do not assume every POST field is accepted on PATCH.
  • Enum casing — enum casing varies by endpoint. Use the exact case shown in each endpoint’s request schema or example.
  • Timestamp filters — filters such as updated_since use ISO 8601 timestamps, for example 2026-05-06T12:00:00Z, not Unix seconds.
  • Filter matching — email filters are exact matches after email normalization. Phone filters are exact E.164 matches. Name filters are prefix/full-text name matches, not arbitrary substring searches.
  • Assignment — assigned_to_id should be a user ID from the relevant book’s GET /v1/books users[].id list.
  • Deletes — the v1 API does not expose DELETE for top-level CRM records. Use resource-specific lifecycle fields where available.
  • Errors — { "error": "<code>", "detail": "<message>" } with the appropriate HTTP status.