List your caller-ID pool, and why each number is or is not displayable
The numbers your organization may display as the caller ID on an outbound bridge, and for each one whether the selector may actually use it, and if not, exactly which screen refused it. Requires the voice:bridge scope.
⛔ READ ONLY, AND THE MISSING WRITE HALF IS THE DESIGN RATHER THAN AN UNFINISHED PART. There is no POST, PATCH or DELETE on this path and there will not be one: every row here is a number somebody paid for that a stranger's handset will display, so adding one is a purchase and retiring one is a reputation decision. Both are operator actions, taken deliberately, out of band. This endpoint is how you and we SEE what was added and why it is or is not being used.
WHY THIS ENDPOINT EXISTS. The selector cannot fail a call: a pool that is broken and a pool that was never configured both end on your organization default number and both produce a working call. So "I added a San Antonio number and calls still come from Sacramento" has no symptom to look at. This endpoint is that symptom, in one request: read refusal on the row instead of placing a call to find out.
⛔ READ pool_status BEFORE YOU READ numbers, AND DO NOT TREAT AN EMPTY LIST AS AN ANSWER. ok with an empty array means you have no pool rows. table_absent means the table backing this feature is not in this database yet, that is the current state, the migration is applied by hand, and the empty list carries no information at all. query_error means the read failed right now and is a DIFFERENT event from "not shipped yet"; collapsing the two is how a broken pool spends a month looking like an unbuilt one. All three come back with HTTP 200, because a caller-ID feature must never be able to refuse a call, so a non-200 is never the way you learn the pool is unreadable.
⛔ selectable: true MEANS ELIGIBLE, NOT "WILL BE USED". Eligible rows still compete: the selector prefers a market match and breaks ties on the lowest row id, so the first number an operator added for a market keeps winning until they retire it. And three further refusals are decided per CALL, against the number being dialled, and therefore CANNOT appear in this response at all, displaying the very number we are about to dial, a row whose channel binding names a different number, and a row that has passed its daily dial ceiling (which is reported as an alert on the call and never reassigns the call to another number). If a number is selectable here and still was not used, those are where to look, in the session record for that call.
⛔ refusal REPORTS THE FIRST REASON, NOT ALL OF THEM. The screen is ordered and stops at the first failure, so a row that is retired AND unverified reports only retired. Fix what it names, read again, and expect a different refusal rather than a pass.
ONE REFUSAL IS ABOUT OUR DEPLOYMENT AND NOT ABOUT YOUR ROW. callback_line_disarmed fires when a row routes call-backs to our own answering line and that line is not armed on this deployment. Nothing you can change on the row clears it, and it is screened deliberately: a returning caller would otherwise reach dead air on a number already in circulation, which is worse than the default number the call would have used.
THE REACHABILITY STAMP IS NOT OPTIONAL AND NO FLAG OVERRIDES IT. A displayed number has to be one the person who sees it can dial back and reach something; two of the state statutes that permit substituting a number say so in as many words. Until an operator has verified out of band that calling the number reaches something, the row is inert and reports callback_unverified.
default_did IS WHERE A CALL LANDS WHEN NOTHING IN THE POOL WINS, your connected Telnyx number, or the first one we hold if none is marked connected. It is reported so you can see the fallback without placing a call to observe it. It is resolved from up to 50 of your Telnyx numbers, so an organization holding more than that should treat both this field and the not_an_owned_telnyx_did refusal as advisory rather than final.
rotation_policy IS THE CONSTANT STRING "none_automatic" AND IT IS ON THE WIRE ON PURPOSE. Nothing here rotates numbers under load, ever. Do not build a rotation client against this endpoint; a number is retired by a human, deliberately.
expected_attestation IS AN EXPECTATION, NOT A MEASUREMENT. It is what we believe the carrier will attest for this number and it has not been verified against live calls. market_label is derived from the number's own area code rather than from the stored market_key, so the two can describe different places on a mis-keyed row, and a market_key that this system does not recognise is refused outright (market_key_unknown) rather than quietly matching nothing.
Request
- Base URL: https://corebee.ai/api/v1
- URL: https://corebee.ai/api/v1/voice/caller-id/pool
- Auth: HTTP bearer
Response
OK. Also the status when the pool could not be read, see pool_status.
Example response
{
"data": {
"pool_status": "table_absent",
"default_did": "+19165550147",
"rotation_policy": "none_automatic",
"numbers": [
{
"e164": "+12105550188",
"kind": "owned",
"market_key": "san_antonio",
"market_label": "San Antonio",
"npa": "210",
"region_code": "TX",
"expected_attestation": "B",
"callback_handling": "staffed",
"daily_dial_ceiling": 500,
"refusal": "callback_unverified"
}
]
}
}Changes
No recorded changes to this operation across all 1 revision of this API.