Embed LeadTracker AI in your voice AI and automation stack.

Authentication

Create an API key from LeadTracker AI app → Developer API. Keys are workspace-scoped, shown once, and use explicit permissions.

curl https://leadtrackerai.com/api/v1/scheduling/brands \
  -H "Authorization: Bearer lt_live_..."

X-API-Key: lt_live_...

SDKs and MCP

The JavaScript/TypeScript and Python SDKs are generated from the canonical OpenAPI document. They stay thin: authentication, request construction, safe retries, cursor pagination, job polling, approval status, request IDs, and structured errors are ergonomic client helpers; tenancy, scopes, entitlements, plans, and policy remain server-owned.

npm install @leadtracker/developer-api

python -m pip install leadtracker-developer-api

import { LeadTrackerClient } from '@leadtracker/developer-api';

const api = new LeadTrackerClient({
  baseUrl: process.env.LEADTRACKER_API_BASE_URL ?? 'https://leadtrackerai.com/api/v1',
  bearerToken: process.env.LEADTRACKER_API_TOKEN,
});

for await (const lead of api.paginate('developer_crm_leads_list', {
  query: { limit: 50 },
})) {
  console.log(lead.id);
}

MCP setup and authority

The MCP adapter is a separate HTTPS client over /api/v1. Configure a short-lived delegated token or least-privilege service credential in the MCP host; never give it a database connection, session cookie, platform-wide credential, or internal route access.

{
  "leadtracker": {
    "baseUrl": "https://leadtrackerai.com/api/v1",
    "tokenEnv": "LEADTRACKER_MCP_TOKEN",
    "scopes": ["leads:read", "jobs:read"]
  }
}

MCP tools are derived from the same x-mcp metadata and capability checks as the public API. Workspace tenancy, scope checks, entitlement gates, idempotency, If-Match, exact plan hashes, approvals, audit, and redaction still run on every request. Human approval ceremonies and OAuth callbacks remain outside direct MCP exposure; MCP may observe status but cannot self-approve.

Remote MCP server (hosted)

The same adapter is hosted at https://leadtrackerai.com/mcp over Streamable HTTP, so ChatGPT developer mode and claude.ai / Claude Desktop custom connectors need nothing installed. One MCP session is one transport bound to exactly one caller credential; the hosted process holds no platform credential and reaches no database. Set MCP_REMOTE_ENABLED=0 to take the endpoint offline.

The endpoint is OAuth-protected and self-describing: an unauthenticated request returns 401 with WWW-Authenticate: Bearer resource_metadata="https://leadtrackerai.com/.well-known/oauth-protected-resource/mcp". Clients read /.well-known/oauth-protected-resource/mcp (RFC 9728) and /.well-known/oauth-authorization-server (RFC 8414), register themselves with POST /api/v1/oauth/register (RFC 7591), and complete authorization code + PKCE S256. The RFC 8707 resource indicator is honoured, so a token minted for another resource is rejected at /mcp; authorization responses carry iss; access tokens live 60 minutes and refresh tokens rotate with reuse detection. Registration is open by design, so it is rate limited per source address and capped globally at 200 new dynamic clients per rolling day. A client that names no scope receives the default connector set only — CRM, scheduling, meetings, projects, chat, forms and tasks read+write plus users:read, approvals:read, and approvals:request. Those approval scopes let a connector request and read a human approval; they never let it decide one. Analytics, audit, webhook management, bulk/archive and workspace or user writes must be requested explicitly and always appear on the consent screen. Existing grants are never widened silently, so remove and add an older default connector again to create a fresh registration with this corrected default set.

A human always approves in the browser. An unauthenticated /authorize redirects to /login?next= and back, then to a consent screen naming the client, the workspace, and every requested permission grouped by domain. The screen may narrow the grant but never widen it, and the grant is revocable under Settings → Developer.

Server URL:   https://leadtrackerai.com/mcp
Auth:         OAuth (dynamic registration — leave client id and secret blank)
ChatGPT:      Settings → Connectors → Advanced → Developer mode → Create
Claude:       Settings → Connectors → Add custom connector
Cursor:       local stdio (see the MCP host configuration above)

A token that acts as a person never exceeds that person's role. Access tokens from authorization code + PKCE (every hosted connector) are bound to one workspace member, and on every request their scopes are intersected with that member's role — including tokens issued before a role changed. Owners and admins keep every granted scope. Managers keep everything except the admin control planes (developer:credentials:admin, developer:webhooks:write, billing:write, users:write, workspace:write, domains:write, integrations:write, phone_numbers:manage, invoices:write, payments:write, commissions:approve). Setters, closers, full-cycle closers and any other role are limited to leads:read, leads:write, deals:read, deals:write, tasks:read, tasks:write, scheduling:read, scheduling:write, meetings:read, meetings:write, calls:read, tags:read, custom_fields:read, pipelines:read, users:read, teams:read, notifications:read, notifications:write, chat:read, chat:write, roleplay:read and roleplay:execute; token introspection and the MCP tool list report the clamped set.

Within those scopes a rep-delegated token sees exactly the records its person sees in the app, and a hidden record answers 404: leads the person created or is assigned to (plus the unassigned pool for setters and full-cycle closers); deals they own (closer) or set (setter); tasks assigned to them; bookings they host or whose lead they can see; meetings they host or are invited to; calls they made or on leads they can see; and only visible smart-list members, lead/deal tags and custom fields. POST /leads/upsert and POST /scheduling/bookings return 409 lead_exists_outside_scope instead of changing another teammate's lead; leads created through the token are owned by the person. Call queues, prospect packs, signal-to-lead conversion and duplicate review return 403 role_denied. Service accounts and workspace API keys can only be created by owners and admins and remain workspace-wide integrations.

Because several hundred tools degrade a model's tool selection, a hosted session lists the essentials profile by default: 203 tools covering leads, deals, pipelines, tasks, scheduling, meetings, forms, projects, chat, smart lists, custom fields, tags, analytics, users, teams, webhooks, and workspace reads. Local stdio keeps the full 791. The consent screen picks the profile and can narrow it to a subset of domains, and the choice is stored on the access token; stdio uses LEADTRACKER_MCP_PROFILE and LEADTRACKER_MCP_DOMAINS. A profile controls tool visibility only; it cannot add OAuth permissions. Profile filtering never grants anything — a tool is listed only when the credential's scopes, the workspace's entitlements, and the profile all allow it, and leadtracker://capabilities reports the exact reason for every omission, including the per-domain paid_only_operations a zero-cost subscription cannot call.

Tools carry MCP annotations so a host can decide what to confirm: readOnlyHint on reads, destructiveHint on archive/delete/cancel/disable, idempotentHint on If-Match updates, and openWorldHint: false everywhere. Booking creation, rescheduling, and cancellation are R2 plan-first actions. The default connector scopes include approval read/request, so the connector can create and check the approval request without “Allow all”; the person in LeadTracker makes the approval decision. An R2 request may be approved by the same person who made it, while R3 requires a different admin and the approval_request_id they granted for that exact plan.

Appointments, consultations, and discovery calls must use the native leadtracker_scheduling_* tools. The generic calendar-entry create tool only adds an internal workspace block: it does not create an attendee booking or send confirmation, reschedule, or cancellation emails. For a workspace with one booking brand, clients omit brand_id and the server selects that brand automatically; configured: null in capabilities means configuration was not evaluated, not that the booking brand is missing.

CRM companies, duplicate review, stage rules and durable jobs

The /crm routes use delegated user credentials and the same record visibility as the application. Service accounts cannot impersonate a member. Mutations require an Idempotency-Key; versioned writes include the opened numeric version.

Owners and admins can review exact-identity duplicate groups with owner_id or normalized identity filters. Preview is capped at 100 groups and returns has_more; narrow or resolve the displayed groups. Reviewed merge requires both opened revisions and a reason, preserves originals in the audit snapshot, transfers associations atomically, and never auto-merges candidates.

Companies support versioned edits and contact associations. Deal stakeholder links authorize the contact and deal separately. Managers can configure stage requirements and approve a specific deal revision. Database rules enforce entry and exit requirements across writers. Task completion creates one recurring successor atomically.

Audience preparation freezes ordered membership, and export preparation also freezes values. Confirm the prepared count before execution. Queued work supports checkpoints, cancellation, per-record errors, and protected downloads expiring after 24 hours. Audiences are capped at 100,000 records; the cap is enforced without partial results.

Working context requires leads:read, tasks:read, deals:read, communications:read and finance:read. Stakeholder and recurring-task creation also require leads:read. Audience actions require leads:bulk, plus tags:write, leads:archive or leads:write for the chosen mutation.

Durable CSV imports use POST /crm/imports, then POST /crm/imports/{id}/start with the exact expected_count. Active owners, admins and managers can validate up to 100,000 rows in a 10 MB file. Row outcomes, validated column mappings, validation errors, reviewed field choices and committed checkpoints are retained for seven days. Import GET/list responses include the current member's saved mappings for reuse. The paginated rows endpoint can collect a complete live CSV error/review report; it is not limited to the displayed page. Cancel and resume preserve completed rows. Duplicate policies are skip, update non-identity fields, or manual review; ambiguous and archived contacts always require review. Custom mappings and reviewed custom updates also require custom_fields:write.

Stage filters retain literal field semantics. Pipeline context is a separate view_context setting; saved views store it as view_state.stage_tab. Calendar-relative filters use the requested timezone and exclusive interval ends.

Canonical operation inventory

Saved Deals and Tasks queues have asynchronous CSV exports with up to 100,000 exact ordered records and selected columns. Native UI and delegated API use the same workspace, role, filter and saved-view checks. Export preparation freezes membership and values; 200-row checkpoints support cancellation and resume without repeated output. Money exports include currency. Artifacts expire after 24 hours and downloads reauthorize membership, view access and every captured record. Owner, admin or manager membership is required. Create through POST /crm/deals/exports or POST /crm/tasks/exports, then inspect, cancel, resume or download through /crm/entity-exports/{id}. Status/download also require leads:bulk and the corresponding deals:read or tasks:read scope. Mutations require an Idempotency-Key; service credentials cannot impersonate a user.

Platform support uses support:read and support:write on every plan. Cases remain limited to the requesting user or service credential; public articles exclude operator notes. Mutations require Idempotency-Key and return durable acceptance with an honest sync state. See the support contract. The authenticated v1 surface contains 774 operations. It includes native scheduling, CRM records and relationships, durable jobs, communications, documents, workflows, finance and governed integrations. This inventory matches the downloadable OpenAPI contract.

The MCP projection exposes 833 tools: 769 direct public-operation tools plus 63 target-specific immutable plan tools. Provider actions retain their reviewed plan and approval contracts. Account-bound CRM operations require delegated user authorization and cannot impersonate workspace members.

Calls and voice assets

Calls are workspace-scoped durable intents. A start request persists its operation and job before any Telnyx request, then applies DNC, international, caller-ID, usage, and human/policy gates. When external effects are disabled, the same request returns a deterministic simulation and never contacts a provider.

Call queues and supervisor floor

Call queues persist ordered lead work in the workspace and use the same call policy gates as direct dialing. Queue start creates durable operation/job intent before a provider request; external-effects-disabled environments return deterministic simulations. For filter-based or smart-list-based queues, use the two-step preview flow: POST /call-queues/preview returns the exact audience count (max 200 leads) and an HMAC-signed preview token; pass that token to POST /call-queues to create the queue without re-resolving the audience. Preview takes calls:read and requires exactly one of smart_list_id or filter. If the audience changed between preview and create, POST /call-queues fails with 409 count_mismatch rather than dialling a different set of people than the one you approved; preview again to get a fresh token.

Phone numbers and AI receptionist

Phone inventory and receptionist configuration are workspace-owned resources. Phone purchases, replacements, and retirement are two-step R3 operations: create a server-side plan, then execute only the exact approved plan. Health checks, DNC/plan/usage gates, and disabled-effects simulation are enforced by the same service boundary used by the app.

Campaigns

Campaign definitions use the same typed steps, merge-field validation, suppression rules, audience compliance checks, usage gates, and trusted worker path as the application. Create a launch plan before execution: the server binds the exact audience, resource versions, projected usage/spend, and plan hash to an expiring operation.

Meetings, coaching, and roleplay

Meetings are workspace-owned resources with explicit host/participant visibility. Create and control them through meetings:write; read scoped recording, transcript, summary, and action-item projections through meeting_artifacts:read. Join grants are one-way, audience-bound, hashed at rest, and expire within the server's short TTL.

POST /meetings requires title and starts_at (ISO-8601 with offset); duration_minutes (default 30), description, timezone, brand, meeting_type, host_user_id (defaults to the caller), location_type, invitees and metadata are optional. The legacy names scheduled_at and organizer_id are still accepted; sending both spellings with different values returns 400 invalid_request. Timestamps in meeting, invitee, artifact and roleplay responses are ISO-8601 strings. A rep-delegated token lists only meetings its person hosts or is invited to.

Projects and private files

Projects expose tenant-owned boards, columns, tasks, checklists, comments, and membership. A held workspace scope is necessary but not sufficient: reads require project membership, while project writes and membership changes additionally require project-admin role checks.

Team chat

Team chat exposes workspace channels, direct messages, reactions, and read markers through the same credential and live-workspace gates as the rest of the Developer API. Room membership and message authorship remain additional authorization checks after workspace scope.

Finance core

Finance core exposes tenant-owned invoices, payments, customer subscriptions, and document lifecycles. Amounts are always integer minor units paired with an exact ISO-4217 currency; floating-point money is never accepted.

Commissions

Commission entries are tenant-owned calculations represented in integer minor units and exact ISO-4217 currencies. Corrections and payout controls never accept raw card or bank data.

Tasks and personal/team calendars

CRM tasks remain backed by lead_tasks; project work is a separate resource. Assignments are checked against active human workspace membership, while service accounts remain creator identities only.

Bounded CRM imports and exports

Move CRM data through bounded, tenant-safe jobs. Imports accept only CSV or TSV files with explicit allowlisted mappings; exports select an explicit public lead projection and produce an expiring artifact.

curl https://leadtrackerai.com/api/v1/leads/imports \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY" \
  -H "Idempotency-Key: crm-import-20260815-01" \
  -F "file=@leads.csv;type=text/csv" \
  -F 'mappings={"email":"contact_email","name":"contact_name","Line type":"phone_line_type","Priority":"custom:12"}'

{
  "data": {
    "job_id": "job_01JIMPORT",
    "status": "succeeded",
    "resource_type": "lead_import",
    "resource_id": "imp_01JIMPORT",
    "simulated": true,
    "import": { "counts": { "rows": 1, "valid": 1 } }
  }
}

curl https://leadtrackerai.com/api/v1/leads/exports \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY" \
  -H "Idempotency-Key: crm-export-20260815-01" \
  -H "Content-Type: application/json" \
  -d '{"lead_ids":[2194],"fields":["id","name","email","company"],"format":"csv"}'

{
  "data": {
    "job_id": "job_01JEXPORT",
    "status": "queued",
    "resource_id": "art_01JEXPORT",
    "artifact": { "status": "pending", "download_url": null }
  }
}

Booking brands

Single-brand workspaces are configured automatically. Each workspace exposes its own tenant-configured brands and routes person-less bookings through that brand's Calendar Round Robin; the API does not use a fixed list of product brands.

curl https://leadtrackerai.com/api/v1/scheduling/brands \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY"

{
  "data": [{
    "id": 17,
    "identifier": "acme-consulting",
    "name": "Acme Consulting",
    "event_type_ids": [42],
    "routing_mode": "round_robin",
    "active_calendar_count": 2
  }]
}

Event types

Fetch the booking types available in the authenticated workspace. Every event type includes its allowed brand records; use a matching brand.id and event type ID when retrieving availability or creating a booking.

curl https://leadtrackerai.com/api/v1/scheduling/event-types \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY"

{
  "data": [{
    "id": 42,
    "title": "Discovery Call",
    "duration_minutes": 30,
    "timezone": "America/New_York",
    "booking_window_days": 14,
    "brands": [{
      "id": 17,
      "identifier": "acme-consulting",
      "name": "Acme Consulting"
    }]
  }]
}

Availability

Slots are returned as UTC ISO 8601 timestamps. Convert them to the caller's local time in your voice experience, then pass the selected UTC start time when booking.

curl "https://leadtrackerai.com/api/v1/scheduling/availability?brand_id=17&event_type_id=42&start_date=2026-08-17&end_date=2026-08-21&routing_key=vapi-call-6d9f08b2" \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY"

{
  "data": {
    "event_type_id": 42,
    "routed_event_type_id": 81,
    "brand_id": 17,
    "brand": { "id": 17, "identifier": "acme-consulting", "name": "Acme Consulting" },
    "routing_mode": "round_robin",
    "routing_key": "vapi-call-6d9f08b2",
    "timezone": "America/New_York",
    "slots": [{
      "start": "2026-08-17T14:00:00.000Z",
      "end": "2026-08-17T14:30:00.000Z"
    }]
  }
}

Create a booking

LeadTracker AI validates the brand/event-type pair, creates a CRM lead or links an exact existing identity, performs a final conflict check, creates the correctly branded native meeting room, writes the connected calendar event, starts reminder delivery, and sends the normal Telegram booking notification. Identity matching is scoped to the API key’s workspace: the same email or phone may exist independently in another workspace. Create-style booking intake never edits an existing lead’s contact, location, or timezone; conflicting identity details return 409 lead_identity_conflict, while unresolved legacy collisions return 409 ambiguous_lead_identity.

curl -X POST https://leadtrackerai.com/api/v1/scheduling/bookings \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY" \
  -H "Idempotency-Key: vapi-call-6d9f08b2" \
  -H "Content-Type: application/json" \
  -d '{
    "brand_id": 17,
    "event_type_id": 42,
    "routing_key": "vapi-call-6d9f08b2",
    "start": "2026-08-17T14:00:00.000Z",
    "attendee": {
      "name": "Avery Chen",
      "email": "avery@northstar.example",
      "phone": "+15125550123",
      "timezone": "America/Chicago",
      "company": "Northstar Health",
      "location": "Austin, TX"
    },
    "source": "vapi",
    "external_reference": "call_01J123",
    "metadata": { "agent": "inbound-sales" }
  }'

{
  "data": {
    "id": "ltbk_9c7bd1...",
    "status": "scheduled",
    "brand_id": 17,
    "brand": { "id": 17, "identifier": "acme-consulting", "name": "Acme Consulting" },
    "routing_mode": "round_robin",
    "routing_key": "vapi-call-6d9f08b2",
    "start": "2026-08-17T14:00:00.000Z",
    "end": "2026-08-17T14:30:00.000Z",
    "meeting_url": "https://leadtrackerai.com/meet/...",
    "lead_id": 2194
  },
  "duplicate": false,
  "lead_created": true
}

List bookings

Use the collection endpoint to reconcile bookings created by the API or the LeadTracker AI app. Results are always limited to the authenticated API key’s workspace and can be narrowed by attendee email, status, or the legacy from/to date filters.

curl "https://leadtrackerai.com/api/v1/scheduling/bookings?status=scheduled" \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY"

{
  "data": [{
    "id": "ltbk_9c7bd1...",
    "status": "scheduled",
    "brand_id": 17,
    "event_type_id": 42,
    "start": "2026-08-17T14:00:00.000Z",
    "end": "2026-08-17T14:30:00.000Z",
    "attendee": { "name": "Avery Chen", "email": "avery@example.com" }
  }]
}

Read a booking

curl https://leadtrackerai.com/api/v1/scheduling/bookings/ltbk_9c7bd1... \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY"

Reschedule a booking

{
  "start": "2026-07-16T16:00:00.000Z",
  "reason": "Caller requested a later time"
}

Cancel a booking

{
  "reason": "Prospect cancelled during the call"
}

Leads

Use the CRM endpoints to identify a caller, create or update a contact, and add durable notes or activities. Email and phone identity checks are workspace-scoped, so two workspaces can independently own the same details; a conflicting email/phone pair in one workspace fails closed for review. They expose a deliberately small CRM-safe field set: no deletion, assignment, campaign enrollment, billing, or bulk export operations are available.

curl -X POST https://leadtrackerai.com/api/v1/leads/query \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": {
      "version": 2,
      "all": [
        { "field": "stage", "operator": "in", "value": ["setter", "closer"] },
        { "field": "lead_score", "operator": "gte", "value": 70 },
        {
          "any": [
            { "field": "tags", "operator": "has_any", "value": [5, 12] },
            { "field": "created_at", "operator": "in_last", "value": { "n": 7, "unit": "days" } }
          ]
        },
        { "not": { "field": "contact_email", "operator": "contains", "value": "gmail.com" } }
      ]
    },
    "sort": [
      { "field": "lead_score", "dir": "desc" },
      { "field": "created_at", "dir": "desc" }
    ],
    "limit": 100
  }'

curl -X POST https://leadtrackerai.com/api/v1/leads/query \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": {
      "version": 2,
      "all": [
        { "field": "search", "operator": "matches", "value": "acme -gmail \"jane doe\" tag:vip" }
      ]
    }
  }'

curl "https://leadtrackerai.com/api/v1/leads?sort=lead_score:desc&limit=50" \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY"

curl -X POST https://leadtrackerai.com/api/v1/leads/upsert \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY" \
  -H "Idempotency-Key: voice-call-01JABC" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Avery Chen",
    "email": "avery@northstar.example",
    "phone": "+15125550123",
    "company": "Northstar Health",
    "timezone": "America/Chicago",
    "source": "retell",
    "attribution": { "utm_source": "partner" }
  }'

Tags and custom fields

CRM taxonomy is workspace-scoped and uses the same API-key or delegated OAuth boundary as leads. Reads require a tags:read or custom_fields:read scope; mutations require the matching write scope, an Idempotency-Key, and If-Match on versioned definition updates and archives.

curl -X PUT https://leadtrackerai.com/api/v1/leads/2194/tags \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: lead-tags-01JABC" \
  -H "Content-Type: application/json" \
  -d '{"tag_ids":[12,19]}'

curl -X POST https://leadtrackerai.com/api/v1/custom-fields \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: field-01JABC" \
  -H "Content-Type: application/json" \
  -d '{"scope":"contact","key":"plan","label":"Plan","type":"select","options":["starter","team"]}'

Smart lists

Smart lists are saved, bounded lead filters. The filter schema is read-only metadata; creation, preview, update, and archive use smart_lists:write, R1/R0 as shown, and replay-safe idempotency. The lead projection requires leads:read.

Filter schema version 2 adds categories, value_kind, relationship fields (tags, custom fields, calls, tasks, notes, appointment), virtual fields (contact_type, safe_email, verified_mobile, verified_owner, wireless_verified), and search rule grammar to the GET /smart-lists/filter-schema response. Filters use the same validator and SQL compilation as the UI saved views and POST /leads/query.

niche is the one governed, user-facing Business category slug (for example dental or real-estate). Its picker options are assembled for the credential's current workspace: the default catalog plus that workspace's active additions. Manual CRM entry and lead enrichment create categories through the same workspace-bound resource; a category created in one workspace is never copied into another. industry is retained only as raw source evidence and for existing saved filters, not as a second user-facing category. Use Business category equality for a category spanning vendor labels such as Dentist and Dentistry. A document's top-level all conditions are ANDed with its any group. The same document semantics apply to the CRM, API, SDKs and MCP tools. Enrichment uses specific row industry evidence before a conflicting batch category, preserves valid specialist categories under broad industries, and leaves existing populated CRM classifications for evidence-based review and repair.

SmartList schema extensions: kind ('segment' | 'view', default 'segment'), sort (array of {field, dir}, max 3), view_state ({columns, hidden, density, page_size}, max 8KB, validated against shared column registry). Saved views support column layout persistence, density, and custom ordering.

curl -X POST https://leadtrackerai.com/api/v1/smart-lists/preview \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: preview-01JABC" \
  -H "Content-Type: application/json" \
  -d '{"filters":{"match":"all","rules":[{"field":"stage","operator":"eq","value":"setter"}]}}'

Pipelines and stages

Pipeline configuration is workspace-scoped and admin-role guarded in addition to the pipelines:read/pipelines:write scope. Every mutation is R1, requires Idempotency-Key, and stage/pipeline updates, archives, and reorders require If-Match.

curl -X POST https://leadtrackerai.com/api/v1/pipelines/7/stages \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: stage-01JABC" \
  -H "Content-Type: application/json" \
  -d '{"name":"Qualified","position":2,"color":"#22d3ee"}'

Deals and forecast

Deals are workspace-scoped pipeline records linked to a lead. Read operations require deals:read (or analytics:read for forecast); create, update, transition, and activity writes require deals:write; archive and restore additionally require deals:archive. All deal mutations are R1, require a stable Idempotency-Key, and versioned writes require the current If-Match value.

curl -X POST https://leadtrackerai.com/api/v1/deals \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: deal-01JABC" \
  -H "Content-Type: application/json" \
  -d '{
    "lead_id": 2194,
    "pipeline_id": 7,
    "stage_id": 31,
    "name": "Northstar annual plan",
    "amount": "12500.00",
    "currency": "USD"
  }'

curl -X POST https://leadtrackerai.com/api/v1/deals/884/move \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: deal-move-01JABC" \
  -H "If-Match: \"deal-884-v3\"" \
  -H "Content-Type: application/json" \
  -d '{"stage_id":32,"position":0}'

Conversations and compliant messaging

Read tenant-owned conversations and messages, explain send eligibility, and queue outbound SMS, WhatsApp, and email messages from a conversation. Recipient addresses are resolved only from the conversation lead; arbitrary recipients, sender IDs, provider IDs, and provider credentials are not accepted.

curl -X POST https://leadtrackerai.com/api/v1/conversations/300/messages \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: conversation-message-01JABC" \
  -H "Content-Type: application/json" \
  -d '{"channel":"sms","body":"Confirmed for Tuesday at 10:00."}'

{
  "data": {
    "status": "queued",
    "simulated": true,
    "outbox_id": "mout_01JABC"
  },
  "request_id": "req_01JABC"
}

User Journey forms

Manage tenant-owned User Journey definitions through draft, immutable revision, publish, unpublish, clone, and archive lifecycle operations. Public links are updated with the same workspace and event-type ownership checks, while archived forms and submissions remain retained.

Submission reads are explicitly PII-safe: request only the projections your integration needs, use cursor pagination for exports, and keep the API key on a trusted server.

{brand} is your workspace's own brand slug — one per public booking/application page you've set up (find yours on the Applications dashboard's User Journey Forms page, or in each page's live URL). Any brand slug your workspace owns works here; it isn't limited to any fixed list.

Every form read returns a serving_area object (configured, enabled, fit_countries, version, etag, updated_at). When it is enabled and an applicant answers from a country outside fit_countries, that submission is still captured in full and still visible in the workspace, but it comes back marked for review, no call is offered automatically, and it is left out of the submission KPI — the form is never blocked or hidden. The rule is skipped whenever it is disabled, the list is empty, or the applicant's country cannot be resolved, and configured: false means the journey has no rule at all. The list is editable both by an authenticated operator in User Journey Forms → Serving area and through PUT /forms/{brand}/serving-area (forms:write), which replaces the list wholesale and requires If-Match with the serving_area.etag you just read — it versions separately from the form, because saving a list creates no form revision. Enabling with an empty list is refused with fit_countries_required rather than stored, since it would flag every applicant. A successful write emits form.serving_area.updated. Server-to-server submissions through POST /forms/{brand}/submissions are not evaluated against it, because the calling socket's country is your application host, not the applicant's.

Hosted links and custom domains

Every workspace gets stable hosted URLs for its public journey, and a workspace with an active custom link domain serves all of them on its own hostname — the API shapes below tell you which URL to publish.

Analytics, attribution, and tracking

Read aggregate funnel, source, velocity, cohort, paid-media, creative, unit-economics, attendance, leaderboard, and data-quality metrics without exposing contact details, answers, session identifiers, provider payloads, or raw query strings. The same surface preserves the existing application funnel contract while adding attribution and event ingestion.

Marketing connections and governed actions

The marketing surface connects workspace-owned provider integrations, goal mappings, consent policy, recommendations, forecasts, and identity resolution. Every operation is workspace-scoped, audited, idempotent, and protected by its exact integrations or marketing scope.

Growth Engine and SEO/GEO

Growth Engine brands, topics, posts, editorial decisions, quality gates, and SEO/GEO reporting are tenant-scoped and entitlement-gated. The surface contains 38 operations and never projects provider credentials, raw OAuth tokens, storage keys, or provider URLs.

High-intent Signals and Prospect Packs

Signals and Prospect Packs add seven workspace-scoped operations for reading high-intent signals, converting a signal into a CRM lead exactly once, and requesting bounded prospect data through typed criteria.

Users, teams, workspace, and agency subaccounts

The Phase 9 control plane adds 30 tenant-safe operations for workspace membership, team tenancy, profile and branding settings, typed notification policies, usage and entitlements, and an agency parent’s explicitly owned subaccounts.

Domains, integrations, onboarding, and settings

The Domains/Integrations/Onboarding/Settings surface adds 22 tenant-bound operations for customer domains, provider connections, carrier registration, email sending domains, and typed workspace settings.

Billing and plan management

Billing adds 8 tenant-scoped operations for safe subscription state, usage, the self-serve catalog, exact downgrades to Free, usage-credit top-ups, and provider-hosted portal sessions. Reads use billing:read; owner/admin mutations use billing:write.

Native workflows and triggers

Build tenant-owned workflows from the validated node catalog, inspect durable runs, and trigger or simulate them through the same scope, plan, idempotency, audit, and disabled-effects gates as the rest of the API. HTTP and webhook nodes accept only prevalidated workspace destinations; provider URLs, storage keys, and raw credentials never enter the public contract.

Jobs, approvals, and audit

Phase 1 operation resources are workspace-scoped and available through the same API-key or delegated OAuth credential boundary. Job reads require a held domain read scope; cancellation requires the execute scope that originated the job.

curl https://leadtrackerai.com/api/v1/jobs?limit=50 \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN"

curl -X POST https://leadtrackerai.com/api/v1/approval-requests \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: campaign-approval-2026-08-14" \
  -H "Content-Type: application/json" \
  -d '{"operation_id":"op_01JABCDEF1234567","reason":"recipient threshold"}'

Service-account control plane

Service-account administration is a human owner/admin control plane. It uses the same workspace-bound API-key or delegated OAuth chain, requires developer:credentials:admin, and never treats a legacy API key as a human administrator.

curl -X POST https://leadtrackerai.com/api/v1/service-accounts \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: create-sa-2026-08-14" \
  -H "Content-Type: application/json" \
  -d '{"name":"Sales automation","purpose":"automation","scopes":["leads:read"]}'

curl -X POST https://leadtrackerai.com/api/v1/service-accounts/sa_01JABCDEF1234567/credentials \
  -H "Authorization: Bearer $LEADTRACKER_API_TOKEN" \
  -H "Idempotency-Key: create-credential-2026-08-14" \
  -H "Content-Type: application/json" \
  -d '{"purpose":"automation","scopes":["leads:read"]}'

Generic event webhooks

Manage workspace-scoped endpoints for the generic event stream with an API key. These routes are separate from the legacy booking webhook settings below and never accept booking lifecycle event names.

curl -X POST https://leadtrackerai.com/api/v1/webhook-endpoints \
  -H "Authorization: Bearer $LEADTRACKER_API_KEY" \
  -H "Idempotency-Key: crm-events-2026-08-14" \
  -H "Content-Type: application/json" \
  -d '{"name":"CRM events","url":"https://hooks.example.com/leadtracker","events":["deal.updated","lead.created"]}'

{
  "data": { "id": "wep_01JABCDEF1234567", "version": 1 },
  "signing_secret": "whsec_one_time_value"
}
// Replay and GET/list responses omit signing_secret.

{
  "data": {
    "id": "whd_01JABCDEF1234567",
    "event_type": "deal.updated",
    "status": "delivered",
    "event": { "api_version": "2026-08-14", "data": { "object": { "id": 91 } } }
  }
}

Booking webhooks

Create endpoints from LeadTracker AI app → Developer API. Endpoint configuration is owner/admin session-only; API keys cannot add a destination or reveal a signing secret.

Errors and limits

All errors include a stable machine-readable code and a request_id for support and diagnostics.

{
  "error": {
    "code": "slot_taken",
    "message": "That slot is no longer available."
  },
  "request_id": "4c0725d0-..."
}

Security practices

Use separate keys for every provider and environment. Give each key a recognizable name, set a practical expiration, and replace it before sharing changes hands.