List your originating numbers and each one's (disabled) voicemail configuration

Every Telnyx DID your organization owns, with the per-number consumer-voicemail setting and the script it would speak, plus the ids of the scripts you may choose from. Requires the voice:bridge scope.

THIS FEATURE IS GATED OFF AND SETTING THE FLAG DOES NOT TURN IT ON. Four independent conditions must all hold before any voicemail is left, and they are AND-ed: (1) the source constant OWNER_DECISION_CONSUMER_MAY_HEAR_SYNTHETIC_AUDIO in lib/voice/voicemail/gate.ts, which is false today and is a code change to alter; (2) the runtime flag ASKOTTO_CONSUMER_VOICEMAIL, which ships unset; (3) a per-DID opt-in, which is the consumer_voicemail_enabled column this endpoint reads and writes and which is false or NULL on every row; (4) an admissible answering-machine-detection configuration, which the account does not currently have, the premium AMD config the bridge dials with sets greeting_duration_millis equal to total_analysis_time_millis, so the "a greeting this long is a machine" rule cannot fire before analysis stops. Condition 4 is a property of the dialing configuration, not of anything you can send here. DO NOT READ THIS ENDPOINT AS "voicemail happens once the flag is set": with the flag set and a number opted in, the first and fourth conditions still hold it closed, and no voicemail is left.

The standing owner decision recorded in source is that the consumer never hears synthetic audio, so PATCH with "enabled": true answers 409 for EVERY organization, EVERY number and EVERY key. Nothing you can send makes it a 200; reversing it is a code change, not configuration. This read reports that refusal up front, enabling_blocked is true and enabling_blocked_reason says why, precisely so you learn it from a GET rather than by tripping the error in your integration.

WORDING IS NOT FREE TEXT ANYWHERE ON THIS PATH. available_script_ids is the complete set of message bodies the system will speak; PATCH selects one by id and REFUSES a string. See the PATCH description for the reason and for the exact field names that are refused.

THIS OPERATION DOES NOT 409 WHEN THE MIGRATION IS PENDING, and that is deliberate rather than an omission: if the columns behind the feature are not in the database yet, the read succeeds with 200, every number comes back voicemail_enabled:false, and schema_pending is true with schema_pending_reason naming the migration. False is also the value once the migration lands, so nothing is lost. PATCH answers 409 in the same situation, because a write cannot be honestly reported as done.