Skip to main content
A lead who did not answer today is not lost. A cadence is the plan for trying again: call on day one, text on day two, call again on day four, tag and stop on day seven. Every contact in a power-dialer campaign is somewhere in that plan, and the queue tells you where.

​
Anatomy of a cadence

Each campaign has its own cadence. Picking a template or another campaign’s cadence copies it, so editing one campaign’s cadence never changes another’s.

​
Steps

Each entry in schedule[] is one step. A cadence uses one of three shapes, and every step in it must share that shape. Every step can also carry:
  • label: a name for the step, shown in the dashboard.
  • doubleDial: dial twice back to back if the first attempt is not answered.
  • call: whether the step dials (enabled) and what the agent says on it. openingMessage is the agent’s first line when the lead answers. screeningPurpose is why you are calling, given when the lead’s phone screens the call. The agent still gives its own name, and the purpose does nothing if the agent has no call screening set up. voicemail: true with a voicemailMessage leaves that message on the step’s last dial, in place of the campaign’s voicemail. Leave any of them out and the agent’s own opening and purpose, and the campaign’s voicemail setting (config.voicemail and config.voicemailMessage on the campaign), apply. Callbacks the lead asked for always use the agent’s own settings. A {{variable}} with no value is read out as written. The structured voicemail action uses hang_up to end without a message or say_message to leave the configured message.
  • additionalActions[]: things to do at this step besides calling. Each has a GHL type of sms, email, add-tag or move-stage. A message carries a body or a snippetId pointing at a GoHighLevel snippet, and an email a subject. A tag action carries tags. A stage action carries pipelineId and stageId. delaySeconds and jitterSeconds hold the action back and spread it out so a hundred leads do not all get the same text at the same second.
A step with only additional actions and no call is fine. That is how “text on day two” works.

​
Send webhooks from native sub-accounts

Native sub-accounts use api-event in additionalActions[] to send an HTTPS POST to your integration. The step is called Send webhook in the builder; api-event is its stored type. Set call.enabled to false for an event-only step, or leave calling enabled to send the event when the call advances without an actionable outcome. Native sub-accounts cannot use GHL message, tag or stage actions; GHL sub-accounts cannot use api-event. A campaign flow has its own Send webhook step, which fires where the flow reaches it rather than on a schedule.
  • url is your public HTTPS receiver, up to 2,048 characters. Credentials, fragments and private network destinations are refused.
  • eventName defaults to cadence.step. It starts with a letter and contains up to 128 letters, numbers, dots, dashes or underscores.
  • data is a static JSON object, up to 16 KiB when serialised. Nested values are preserved. Text such as {{contact.email}} stays literal.
  • delaySeconds and jitterSeconds control when the event is queued.
The signed event includes current contact, campaign and cadence details alongside your custom data. Delivery may retry with the same event ID; your receiver should deduplicate by that ID. Saving and reopening a cadence preserves the URL, event name, custom data and whether the step calls.

​
Editing a cadence safely

Leads are mid-cadence while you edit, so the update request carries the guards.
  • schedule replaces the steps.
  • deletions[] names removed steps by index with a strategy: advance moves leads sitting on that step to the next one, remove takes them out of the cadence.
  • stepOrder reorders steps. Reordering changes what waiting leads do next, so it is refused unless confirmReorder: true.
  • allowEmpty: true is required to save a cadence with no steps.

​
The queue

The queue is the live view of who is waiting for what.
  • The pipeline steps endpoint returns how many leads sit on each step of a campaign.
  • The pipeline leads endpoint lists them. Each lead carries queueId, its cadenceStep, callStatus, nextCallTime, whether it is live, whether it is a callback, and pipeline, which names the queue holding the lead: v2 is the current queue and v1 older rows. Act on leads by their queueId rather than branching on pipeline.
  • Callback leads are the people who asked to be called back and are queued for it.
  • Parked speed-to-lead leads are the leads waiting for the calling window to open. See Speed to lead and power dialer.

​
Moving leads by hand

Three actions act on leads that are waiting. A lead on a live call or already finished is skipped, and the response lists each skip with its reason.
  • Run now places the lead’s next touchpoint immediately, ignoring its nextCallTime.
  • Move puts leads on another step. targetStep is zero-based, so 0 is the first step.
  • Remove takes leads out of the cadence.
Each accepts a list of queueId values, or selectAll: true to act on the whole outstanding backlog matched by your filters. Selecting all on a busy campaign can start a great many calls. Read the counts from the pipeline steps first.

​
Boundaries

  • A cadence belongs to one campaign. Editing it changes only that campaign.
  • Steps are relative to when the lead entered, not to the calendar, except clock-time steps, which pin the time of day.
  • The calling window always wins. A step due at 3 a.m. waits for the window.
  • The power dialer does not decide outcomes. The campaign workflow does, after each call.

​
In the API