Pulling statuses & deposits back

Field by field: the second endpoint that tells you what happened to a lead after you sent it.

Sending a lead is half the job. The other half is finding out what the partner's call centre did with it — answered, not interested, deposited. That comes from a second endpoint you poll on a schedule, and it is the part of the template with the most fields. This page goes through them in the order the form asks.

It is optional. Skip it and delivery still works; you just won't see call statuses or deposits, and your conversion numbers will stay empty.

The endpoint and its window

Pull URL, method and body format come from the partner's docs, same as the send endpoint. GET is fine — the request body becomes the query string.

Most partners want a date range, so the request body takes window macros that the CRM fills at poll time. Pick the one matching their format: {from} / {to} render “YYYY-MM-DD HH:MM:SS”; {from_date} / {to_date} are date-only; {from_iso} / {to_iso} are ISO-8601 UTC with a trailing Z; {from_ddmmyyyy} / {to_ddmmyyyy} are day-first. Anything else in that body — a fixed type=3, an account id — you type literally.

Polling is tiered by lead age: new leads are checked every twenty minutes, older ones progressively less often, so a month-old lead isn't re-polled at the same rate as this morning's.

Authentication is automatic

The pull reuses the template's main auth and the same partner credentials — you do not re-enter anything. “Extra headers” is only for a non-secret literal the endpoint additionally requires, such as Accept: application/json, and for most partners it stays empty. Never put an API key there: it would sit in the template as fixed text, shared by every partner using it.

Finding your lead in their reply

The partner returns a batch. Three fields tell the CRM how to read it:

• List path — where the array of items sits in the reply, e.g. rows or data.leads. Leave it empty if the whole reply is the array. A map keyed by id works too.
• Match field — the field inside each item holding the partner's own lead id. This must be the same id your Response parsing saved as “Lead ID path” when the lead was sent — that is how a row is tied back to your lead. Get this wrong and statuses simply never update.
• Status field — where the status value sits inside each item. Dot-paths work here, e.g. registration.rawStatus.

Then the status mapping turns their vocabulary into yours — the single most valuable field in this section, covered in its own page below.

Telling a deposit from a status

Partners signal a first deposit in one of two ways, and the form supports both because you don't get to choose which one they use:

• As a status value — their status becomes something like “Deposited”. Put that value in “Deposit/FTD statuses”.
• As a separate flag — a field such as isDeposited: true or hasFTD: 1 sitting beside the status. Put the field in “Deposit field” and the values that mean yes in “Deposit field values”.

If the partner does both, fill both — they are checked independently and a deposit found either way is recorded once.

When depositors come from a different endpoint

Some partners split it: one endpoint for call statuses, another for depositors, or the same URL with a different parameter (acq=0 versus acq=1). That is what the second, separate deposit-pull section is for — same shape, filled in only when this applies. Most integrations never need it; leave it off.

Checking it works

• Statuses never change — the match field doesn't correspond to the lead id you stored on send. This is the usual cause by a wide margin.
• Some leads update, others never do — those leads were sent before the pull was configured, or the partner's window doesn't reach back far enough.
• Statuses arrive but look like the partner's raw wording — the status mapping is empty.
• Deposits never register — the deposit signal is the other of the two kinds, or the value doesn't match exactly.