Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.slant.app/llms.txt

Use this file to discover all available pages before exploring further.

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

​
Base URL

https://api.slant.app/v1

​
Authentication

Every request must include an Authorization header using the Bearer scheme: 
Authorization: Bearer slnt_pat_<token>
Tokens are issued from the API tokens settings page. Personal access tokens are read-only by default. To request write access for a token, click Request write access from the API tokens settings page and explain why you need it. 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: 
curl https://api.slant.app/v1/me \
  -H "Authorization: Bearer slnt_pat_..."

{
  "id": "abc123xyz",
  "email": "you@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "api_access": {
    "auth_type": "personal_access_token",
    "scope": "read_write",
    "can_write": true
  }
}

​
Rate limits

Every request is checked against three buckets. The strictest bucket wins, and exceeded requests return 429 Too Many Requests.
BucketPersonal access tokenOAuth app (default)
Per token / per user1,000 req / hr500 req / hr
Per company / per app10,000 req / hr1,000 req / hr
Per IP10,000 req / hr10,000 req / hr

​
Idempotency

Safely retry POST and PATCH requests by including an Idempotency-Key header with a unique value (a UUID works well): 
curl -X POST https://api.slant.app/v1/prospects \
  -H "Authorization: Bearer slnt_pat_..." \
  -H "Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000" \
  -H "Content-Type: application/json" \
  -d '{ "book_id": "...", "first_name": "Jane", "last_name": "Doe" }'
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.