> ## Documentation Index > Fetch the complete documentation index at: https://docs.hubtalk.ai/llms.txt > Use this file to discover all available pages before exploring further. # Web API > How your system launches campaigns on its own: where to start and where everything is documented. # Web API: how your system launches campaigns on its own This section explains what the Web API does, how to get an access key, how to launch a calling campaign through it, and how to read the responses. This section has two parts, written for different people: * **How it works** requires no programming knowledge: what happens, who is responsible for what, and what has to be decided before the first request. * **Technical reference** is for a developer: request paths, fields, response formats, error codes, and examples. **How to read the contract.** Everything named in a table is stable unless the table says otherwise. Two things are explicitly **not** part of the contract: `error.message` (English diagnostic prose) and the `message` field that may appear inside `blockers` / `warnings` items on `2xx` campaign responses. New fields and new codes are added over time — treat unknown fields as opaque, and an unknown code by falling back to `error.type` + `error.status`. ## What this is and why Normally a person creates a calling campaign: they log in to the dashboard, create a campaign, upload a file with phone numbers, and click **Launch**. That works well while campaigns are occasional. The Web API is for when a campaign has to launch **by itself** — from your system, at the moment an event happens there. A contract goes past due, a ticket closes, a reminder date arrives — your system sends the platform a single request and the campaign starts. No person is involved at that moment. **The key property: under the hood this is the same product.** A campaign created by a request is no different from one created in the dashboard. The same pre-launch checks, the same number parsing, the same do-not-call registry, the same scheduler, the same per-number frequency caps, the same call recordings and reports. It appears in the dashboard in the common list and can be paused by hand. This is not "a second product for developers" — it is a second door into the same one. ## Two working models — pick one | | **Individual calls** | **Campaigns** | | ----------------------------------- | -------------------------------------------- | ------------------------------------------------------------ | | What you send | one number at a time | a list of numbers (and more batches later, if you need them) | | Request | `POST /v1/calls/phone` | `POST /v1/campaigns` | | Who controls the pace | you | the platform | | Who retries no-answers | you | the platform, **if you allowed retries** | | Who watches working hours | you | the platform | | Who checks the do-not-call registry | the platform | the platform | | When it is convenient | your system already knows how to be a dialer | you want to hand over a list and get results | There is no need to mix them in one task: if you hand over a list as a campaign, the platform decides itself whom to call and when, and interfering "from above" with individual calls breaks its pacing calculation. The rest of this page is mostly about **campaigns** — the reason the Web API is usually connected in the first place; individual calls are covered in [Individual calls](/v4/web-api/calls). ## How it works Issuing a key, what must be ready before the first request, and the pre-launch checklist. What happens after the request, how to read the response, and why the idempotency key is mandatory. Consent attestation, the do-not-call registry, and what the platform does itself. The common refusals, what they mean and what to do about them. ## Technical reference Base address, authentication, formats and the map of every request. `POST /v1/campaigns`: headers, request body, the order of refusals. What comes back, and how to read launch blockers and warnings. Retries, numbers, dial binding, consent, registry screening, idempotency. Launch, pause, cancel, progress, statistics and adding batches of numbers. What came back for each row of the file, and the row-level issue codes. `POST /v1/calls/phone`, the call object, reading, ending and listing. The outcome axis: `call_status`, `status_reason` and how they fold into a verdict. The `call_ended` and `call_analyzed` events, signing, retries and delivery order. The full list of codes and a working scenario in one piece.