REST API

One REST API for the whole outbound pipeline.

Register leads, run campaigns, manage suppressions, keys, and webhooks — the same primitives the dashboard itself is built on, exposed as a clean, versioned /api/v1 surface with a published OpenAPI 3.1 spec, so you can build against it instead of clicking through it.

Client/API/V1Bearer pk_live_…GATEWAYPOST/v1/leadsPOST/v1/campaigns/:id/runGET/v1/sendsPOST/v1/webhooks{ }

The problem

A UI is not an integration surface.

[ 01 ]

A stitched-together UI, not a system

Clicking through screens to register leads and launch each campaign works for one person, one time — it does not connect to your own systems.

[ 02 ]

No stable contract to build against

Without a published, versioned spec, integrating for production is a bet on an API that could reshape underneath you at any point.

[ 03 ]

One shared credential, no delegation

UI-only tools often have no scoped keys — every script, teammate, and integration ends up holding the same full-access login.

[ 04 ]

Every campaign run needs a human at the button

Wiring an intake form, a CRM, or a cron job to trigger a send needs a callable endpoint — not someone remembering to click "run."

How it works

Three calls, one pipeline.

Authenticate, register a lead, and trigger a send — the exact same primitives the dashboard calls under the hood, callable directly from your own code.

[ 01 ]

Authenticate once, per request

Every call carries a Bearer pk_live_ key minted from Settings → API keys — the same credential shape whether it hits a session-based dashboard route or a server-side integration.

auth
curl https://api.cognilead.ai/api/v1/leads \
  -H "Authorization: Bearer pk_live_..."

[ 02 ]

Register a lead — and run it, if you name a campaign

A bare body registers the lead behind the suppression + verification gate. Add campaign_id and the same call continues straight into personalize → dispatch.

POST /api/v1/leads
curl -X POST https://api.cognilead.ai/api/v1/leads \
  -H "Authorization: Bearer pk_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 8f2c-..." \
  -d '{
    "company_domain": "acme.com",
    "best_contact_email": "lead@acme.com",
    "jurisdiction": "US",
    "campaign_id": "camp_123"
  }'
# 201 { "id": "...", "pipeline": { "proceed": true, ... } }

[ 03 ]

Trigger a send on your own schedule

Run synchronously for an immediate tally, or pass async: true to enqueue durable jobs the scheduler retries with backoff — your cron, not a click, decides when it fires.

POST /api/v1/campaigns/:id/run
curl -X POST \
  https://api.cognilead.ai/api/v1/campaigns/camp_123/run \
  -H "Authorization: Bearer pk_live_..." \
  -d '{ "async": true }'
# 202 { "campaign_id": "camp_123", "status": "active",
#        "enqueued": 4, "job_ids": [...] }

[ 04 ]

One request in, one structured response out

Every route sits behind the same /api/v1 boundary — the same suppression, rate-limit, and idempotency handling regardless of which endpoint you call.

Client/API/V1POST/v1/leadsPOST/v1/campaigns/:id/runBearer pk_live_…{ }

The surface, live

Every call runs through the same gates the dashboard does.

Suppression checks, rate limits, and idempotency are enforced server-side on every request — not something a client has to opt into or get right on its own.

API request log — illustrative example traffic5 requests

Illustrative example requests against the CogniLead API

  • POST/api/v1/leads201118ms
  • POST/api/v1/leads40942ms
  • POST/api/v1/campaigns/{id}/run20264ms
  • GET/api/v1/suppressions20031ms
  • POST/api/v1/webhooks20155ms

[ 01 ]

52

Documented routes in the OpenAPI spec

[ 02 ]

Bearer pk_live_ + RBAC

Auth model

[ 03 ]

Up to 300 / min

Per-key write limit (leads, suppressions)

Built for your code, not just your browser

Nothing you can do by clicking, you can't do by calling.

Leads, campaigns, suppressions, keys, and webhooks — the same primitives, the same gates, the same guarantees, callable directly from your own systems.

52 documented routesOpenAPI 3.1 specBearer pk_live_ auth
Client/API/V1POST/v1/leadsPOST/v1/campaigns/:id/runBearer pk_live_…{ }

FAQ

Questions about the API.

At /api/v1/docs — a browsable Swagger UI for the published OpenAPI 3.1 spec, with every endpoint, request/response shape, and auth requirement. The raw spec is also served at /api/v1/openapi.json.

Every request carries a Bearer pk_live_ key, minted from Settings → API keys. Keys are role-scoped (viewer / member / admin) and an admin can only mint a key at or below their own role.

Yes — send an Idempotency-Key header on a POST and a retried request with the same key replays the original response instead of running the handler twice.

The REST API and the MCP server (see /mcp) sit on top of the exact same pipeline — nothing is exposed to one surface and hidden from the other. Use REST for your own backend, MCP for an AI agent.

Prefer an AI agent to call this for you? See the MCP server, or read the full docs.

Your leads deserve to reach an inbox.

Every email you send without protection is a gamble on whether it reaches the inbox at all. Bring your leads — CogniLead handles the warmup, the safety checks, and the cleanup, so you don't have to think about deliverability again.

100 sends a month, free forever · no credit card · cancel any time

REST API — CogniLead