Menu · Changing your CRM
Changing your CRM

Apply a change to your CRM

POSThttps://api.ruuster.com/v1/crm/changes/{changeId}/apply

Step two of changing your CRM. Confirms a previewed change and makes it in your CRM, person by person, checking each one against what the CRM answers. Needs confirm=true from the person who previewed it. Large changes run in batches; call again with the same changeId to continue.

  • Authentication: x-api-key and x-email headers of an owner or admin
  • Rate limit: lookup call, 20 per minute per key, within the 120 per minute
  • Changes your CRM only after a preview and an explicit confirmation; needs the x-crm-write: allow header. Every change is kept on record
  • Your CRM: x-crm-vendor and x-crm-key headers with your CRM's API key, used for this request only. See Connect your CRM
View as Markdown

Makes a change you previewed with Preview a change to your CRM. Only call it after the person has seen the preview and said yes: confirm: true records that they did.

The brakes, in order: the change must still be proposed (or applying, to continue); it must be confirmed by the same Ruuster login that previewed it; the first confirmation is refused within 8 seconds of the preview (409 crm_change_too_soon, so nothing can preview and apply in one breath without asking) and after 15 minutes (409 crm_change_not_open); the CRM key must be for the same CRM account the preview used; and Ruuster's own switch for CRM changes must be on.

Each person is then changed one at a time, spaced to stay inside Follow Up Boss's rate limits, and checked: Ruuster compares what Follow Up Boss answers (and, if needed, a fresh read) with the intended result, so a change the CRM silently ignored is reported as failed, never as done. One call works for about 17 seconds, roughly 35 tag, stage or assignment changes, or 15 notes. When people remain, status stays applying and next says to call again with the same changeId and confirm: true; the person's confirmation stands for the rest of that change. A rate limit or an outage pauses the change without losing it.

Needs your CRM key (x-crm-vendor, x-crm-key) and x-crm-write: allow.

Path parameters

Name Type Description
changeId string The change, crmchg_…, from Preview a change to your CRM

Body

JSON, Content-Type: application/json.

Name Type Required Description
confirm boolean yes Must be true: the person saw this change's preview and said yes

Response

Field Description
changeId, summary The change
status applying (people remain), completed, or completed_with_errors
counts done, failed, skipped, remaining across the whole change
thisBatch[] The people this call handled: personId, name, status (done or failed), reason
next What to do when people remain, or null
pausedBy Why this batch stopped early (a CRM rate limit or outage), when it did