Tune API

Two pipeline fields, not one

recordingUnavailableUpstream is the phone system's own retention expiry — nothing can recover it and it is not a Tune failure. Adding it to recordingFailedOther and plotting the total reports a vendor's retention policy as if it were an error rate.

daily can start a day before from

Buckets are computed in the store's own timezone, so a call at 2026-08-01T00:30Z belongs to July 31st in Central time. That is correct — it is the day the shop had it — but a client charting the series should expect an extra leading bucket.

One row per rep per store

Someone who worked at two stores in the period appears twice, with their calls filed where the work actually happened. Do not add those rows together and call the result one rep's average — group by employeeId and recompute, or state which store you mean.

A line that did not apply is not a miss

Some lines only arise when the call goes a particular way — handling an objection needs an objection. A call where the line never came up is left out of both passed and calls, the same way the score itself treats it. So calls differs from line to line, and is often well below scoredCalls.

Read the denominator before the percentage

A rep with 3 PMI calls can show 0% or 100% on a line off a single call. calls is shipped beside every passPct for that reason. Decide a minimum before ranking anyone on it.

Days are the shop's days

from and to are calendar dates read in the timezone of the key's first store, and each call is filed under the day it happened at its own store. Store Metrics and Rep Metrics take instants instead, so the same dates on those endpoints include or drop the calls either side of local midnight. Use this endpoint when the number has to match the page.

One row per rep here

Unlike Rep Metrics, a rep who worked two stores is a single row with all their calls. That is how the page's leaderboard counts them.

It reads every call in the range

A month across ten stores is about twelve thousand calls and takes a few seconds. Ask for the range you need rather than polling a year.

No date range means all time, not 30 days

Unlike the other metrics endpoints, from and to default to unbounded. Outstanding declined work is a running balance built up over years — around $14.9M across the ten shops — and only a few hundred thousand of that was declined in the last month. A rolling-30-day default would answer a different question with a number that looks like the answer to this one.

Recovery is a match, not a credit

A job counts as recovered when the same work later turns up authorised for that customer. Nothing here establishes that a callback caused it — they may simply have come back. Report it as work that returned, not as revenue the callback programme generated.

Booked is the commitment, came back is the sale

bookedCents is what the rep logged on the call; cameBackCents is work Tekmetric later shows authorised. They are different claims and will not match — show them side by side, and add them only as a total of value derived.

Days are the store's own

Every date is the store's calendar day in its own timezone, so a day's rows for a Central and an Eastern store cover different hours of UTC.

One row per rep here, not per store

Unlike rep metrics, a rep who called for two stores is one row with two byStore lines. The headline numbers are the sum of the lines.

The dates are when the call was made

from and to filter the day of the callback, not the day the work was declined. /api/v1/metrics/declined filters on the declined date, so the same range on the two endpoints is two different sets of work. Omitted, both mean all time.

Booked and recovered are not the same claim

booked is what the rep logged at the end of the call. recoveredAfterCallCents is work Tekmetric later shows authorised. Neither establishes the call caused it, and they will not agree: a customer who says yes and never comes in is booked and not recovered.

Two recovered figures, and the table shows the second

recoveredAfterCallCents on the rep is work that came back after any call of theirs. byStore[].recoveredCents is work that came back where they were the FIRST to call, and it is the one printed on the team table. It is windowed on the day the work was declined, while callbacks is windowed on the day the call was made — the board passes one period to both, and so does this.

from and to do not filter everything, or the same thing

They mean here what they mean on the page. totals, stores and recovery are the work DECLINED in the period. recovered is the work that CAME BACK in the period, so it will not equal totals.recoveredJobs. queue is the visits declined in the period, and with a period set it includes visits too recent to call. stages, queue.byStage and outcomes ignore the period entirely: a stage is defined by how old a decline is, and an outcome is where a visit stands now.

Stages count visits, Declined Totals counts jobs

A visit is one repair order and usually carries several declined jobs. byStage on Declined Totals is in jobs and cents; stages here is in visits, the unit the worklist lists. Neither is wrong and they will not add up to each other.

The curve can run past the period

recovery.series follows work declined in the period to the day it came back, which is often in the next month. That is why its last date can be later than to.

These rows name a customer

Every row carries a real person's name and mobile number. That is why this endpoint needs declined:read, which is granted separately and never implied by metrics:read. Treat the response as customer data: do not log it, cache it in a browser, or forward it anywhere the rest of your customer records would not go. If you only need to chart declined dollars, ask for the totals endpoint instead.

The order is the work

Rows come back earliest-stage first, and most valuable first within a stage, because a day-3 call still has the full quote to offer and is worth more than a day-30 discount on the same job. A consumer that takes the first page and stops has taken the right calls rather than an arbitrary fifty.

A job leaves the list once it has been called

When a callback is matched to a job at its current stage the row disappears until the next stage falls due — so one call does not discharge every later follow-up. Totals therefore fall during a working day without anything having been recovered.