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

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.