One bearer key, five services, one hosted MCP server, prepaid pay-per-call. The 60-second map of how STELQ fits together before you drill into any single reference — the orientation a per-service Quickstart structurally cannot give you.
STELQ exposes five live services under https://api.stelq.com. Four are a single POST endpoint; Monitors is a small route family (create, read, edit, pause). They share one auth model, one wallet, and one error vocabulary — so once you can call one, you can call all five. Each row below links to its own Docs reference for the full parameter set; this page is just the map.
| Service | Route | Price | Shape |
|---|---|---|---|
| Search | POST /v1/search/query | $0.001 / query | sync |
| Content | POST /v1/content/extract | $0.002 / page | sync |
| Answers | POST /v1/answers/ask | $0.002 / answer | sync |
| Research | POST /v1/research/run | $0.08–0.40 / job by depth | async |
| Monitors | POST /v1/monitors/create (+ read/edit/pause routes) | $0.05 / block to create · $0.01 / check / block | standing |
query (or queries for a batched multi-query call); modes auto/web/news/academic, freshness_days, preferred/excluded domains.Same auth, same wallet, same error shape across all five. What differs service to service is the request body and the shape: synchronous (three), async submit → poll (Research), or standing (Monitors — create once, read events back). Wire the plumbing once; reuse it everywhere.
A single key authenticates every service. Send it as a bearer token on every request — Authorization: Bearer $STELQ_KEY — and the same key works across all five. Create keys in the console under API Keys; the secret is shown once. See Authentication for live vs test keys and what "scope" actually means.
Every successful call debits one prepaid wallet. There are no subscriptions and no per-service plans: you top up credits, and each call subtracts its fixed per-service cost. An empty wallet returns 402 — top up to continue. See Billing & credits for top-ups and auto-reload.
There are two transports for the exact same call. You can hit the REST endpoint directly, or reach every service as a native tool through one hosted MCP server at https://mcp.stelq.com/v1/mcp (the same worker also answers at api.stelq.com/v1/mcp). Either way the call runs through the same handler, debits the same wallet at the same per-service cost, and authenticates with the same bearer key — REST and MCP differ only in how the request reaches the gateway, never in what it costs or returns. See Connect an agent to wire up MCP.
curl -X POST https://api.stelq.com/v1/search/query \
-H "Authorization: Bearer $STELQ_KEY" \
-H "Content-Type: application/json" \
-d '{"query": "best ai search infra 2026", "limit": 10}'Three of the five services are synchronous: one request in, one response out. Search, Content, and Answers each return their result on the same HTTP call — there is nothing to poll, no job handle, no webhook. Send the POST, read the body. Research is async (submit → poll) and Monitors are standing (create once, read events back) — both covered by their own guides.
Research is the only asynchronous service. POST /v1/research/run charges by depth ($0.08 quick, $0.25 balanced, $0.40 deep) and returns a job handle instantly — { id, status: "queued" } — and the job runs in the background (most jobs finish in 5–15 minutes; a deep job can run longer). You then poll GET /v1/research/run/{id} until the status is terminal, or pass an optional webhook on submit to be notified on completion. Polling is free and always remains the source of truth. Treat the job handle — not a timer — as the source of truth, and don't set a client timeout below 30 minutes.
Async polling, completion webhooks, and idempotency keys are Research-only mechanics. They do not apply to Search, Content, or Answers — those are plain synchronous request/response. The full submit-then-poll lifecycle, the signed completion webhook, and the Idempotency-Key contract are taught in Async research.