Built on CALL-E
A call can come backperfectand have gone nowhere.
Finished. Job marked done. Confidence nine out of ten. A schema-perfect answer sitting right there in the response. And an answering machine on the other end, which nothing in the payload will tell you.
This reads what actually happened, and points at the field it read it from.
No sign in. Nothing stored. The numbers it can dial belong to nobody.
The same call, twice over
One of these is what you get. The other is what happened.
What the API returns
- status
- completed
- task_completed
- true
- completion_confidence
- 0.9 high
- structured_result
- present
Every light is green. This is the shape almost every integration branches on.
What happened
A recording picked up. The job was reported done.
Nobody can say a person was on the line.
read from recipients[0].structured_result.answered_by
read from task_completed
Same payload. Nothing added, nothing guessed. Every sentence points at the field underneath it, and where no field carries the answer it says that instead.
What it does
Splits the one word into three
How the call ended, whether the job got done, and whether the answer came from anybody speaking. A status field jams all three together, and that is where the money leaks.
Says what it cannot see
The API carries no answered-by field unless you ask for one. So when nothing establishes a person, it says so plainly and names the one field to add. It nags with the fix attached.
Catches the calls nobody is watching
Queued for forty minutes with nothing dialled. A repeat that looked like a new call. A duration the event stream flatly contradicts. Each one is somebody's open bug report, written as a check that runs.
Try it
Call the speaking clock and watch it happen.
Two calls to the same number, one asking who picked up and one not. Both come back finished with the job marked done. Only one of them can tell you a recording answered.
Place both callsIt dials the US speaking clock, which answers instantly and hangs up on itself.