Skip to main content

​
The access key and getting ready

​
The access key: how to get it and what to do with it

The key is a long string your system uses to identify itself to the platform. It replaces a login and password: a program has no person to type those in by hand.

​
How to issue one

  1. Log in to the dashboard with the account of an administrator or developer of your organization.
  2. Open the API keys section in the left menu — it is a top-level menu item, not a subsection of Settings.
  3. Click Create key.
  4. Fill in:
    • Name — for you, so that you can later tell whose key it is (“Billing”, “CRM production”). It is not used in requests.
    • Requests per minute limit — how many requests per minute this key is allowed. Empty or 0 means the platform-wide limit (usually 60 per minute; the exact value in force is shown next to the field). The limit protects you too: a broken integration will not flood the queue.
    • The privileged key checkbox is visible only to platform administrators and is not needed for calling: every operation in this document works with an ordinary key.
  5. Click Create.
The secret is shown exactly once. The dialog displays a string of the form cfk_…. Copy it and hand it to your developer over a secure channel — the platform stores only a hash and cannot show the secret again. If the secret is lost, revoke the key and issue a new one.

​
What else you can do

  • Change the request limit — with the pencil icon in the list. The secret does not change, so the integration needs no reconfiguration; the new limit applies from the next request.
  • Revoke a key — the row stays in the list marked as revoked (needed for audit), but requests with it stop working immediately.

​
What the key cannot do

  • Reach beyond your organization. The key sees only its own campaigns, agents, lines, and uploads. Anything outside that boundary is not “forbidden” for it — it simply does not exist for it: the answer is the same as for an object that never existed.
  • Replace telephony configuration. The key does not create lines and does not bind agents to them: an administrator does that in the dashboard.

​
Why it matters WHO issued the key

The platform records which employee issued the key and when. This is not an audit formality but a legal basis: launching a campaign requires a signature under the attestation that you have the subscribers’ consent, and the signature is placed by the key — that is, by a program. A program’s action holds only as long as it can be tied to the person who took on the obligation. That person is the one who issued the key. The “who and when” record is stored in the signature itself and is not assembled after the fact. Practical conclusion: issuing a key is not a technical detail. It should be issued by someone entitled to answer for calling campaigns on behalf of the organization.

​
What must be ready before the first request

Everything listed here is configured in the dashboard once; without it a campaign will not start, and the platform states plainly what is missing. A note on binding: if the agent is bound to exactly one outbound subgroup, you do not have to specify anything — the platform finds it by the agent. If there are several, it will not choose for you and will ask you to name the line explicitly: guessing here would mean calls from someone else’s number and against someone else’s quota, and you would find out from the invoice.

​
Checklist before the first launch

  1. The agent is created and published; a test call from the dashboard works.
  2. The agent is bound to an outbound subgroup; if there are several, you know which one to name.
  3. For the US: the market package is installed and the list of numbers contains the geography columns.
  4. The organization’s calling window is set the way you need it; a campaign’s working hours cannot widen it.
  5. The key was issued by someone entitled to answer for calling campaigns, and the secret was handed to the developer over a secure channel and stored in your secret storage.
  6. The key’s request limit was set deliberately.
  7. Your system generates a new idempotency key for every new campaign and every batch.
  8. The campaign purpose (classification) is set explicitly and matches what the agent actually talks about.
  9. It is decided who retries no-answers — you or the platform — and the number of attempts is set accordingly (the default is one).
  10. The first campaign was launched on a short list of your own numbers, the response was read in full, and the per-row report was reviewed.
  11. You verified that the campaign is visible in the dashboard and can be paused by hand — this confirms the integration works with the same product.
  12. It is clear who on your side reads progress and what they do with blockers if a campaign fails to start overnight and nobody notices.
What follows is for the developer: how to call the API, which request does what, and what comes back.
Three contract changes from 22 September 2026 — check how you parse responsesAlong with the removal of the shared dialing ceiling (see dialing speed), three fields left the responses. None of them is replaced by anything else — they are simply gone, because so is the mechanism they reported on:
  • warnings[] on campaign creation carries no rate_clamped code;
  • the GET /v1/campaigns/{id}/progress response has no rate.clamped field;
  • in the campaign limits, max_dials_per_minute is replaced by calls_per_minute_tiers, the list of available tiers.
A parser that reads rate.clamped without checking whether the key is there will break on this. calls_per_minute always equals what you sent.