Call Details

Your API key for authentication.

Use your own Twilio account and only return inbound numbers associated with that account sid (optional).

The unique identifier of the call for which you want to retrieve detailed information.

An array of phrases spoken during the call.

Each index includes:

• id
• created_at
• text
• user (can be user, assistant, robot, or agent-action)

The unique identifier for the call.

The length of the call in minutes.

Number that the person was transferred to.

If the call is part of a batch, it’s batch_id will be here.

The phone number that received the call.

The phone number that made the call.

Details about parameters in the original api request.

Whether the call has been completed. If it differs from the value of ‘queue_status’, this will be the most up-to-date status.

Whether the call was inbound or outbound. Will be false for outbound calls.

The timestamp for when the call request was created.

The time the call was connected.

The time that the call will automatically be ended at if it’s still connected (because of max_duration).

The status of the call. During extremely high volume periods, calls may be queued for a short period of time before being dispatched.

The url of the deployment that the call was handled on. Will always be “api.prod.bland.ai” unless the call was handled on a custom Enterprise deployment.

The maximum length of time the call was allowed to last. If the call would exceed this length, it’s ended early.

If an error occurs, this will contain a description of the error. Otherwise, it will be null.

Variables created during the call - both system variables as well as generated with dynamic_data or Custom Tools.

For example, if you used a dynamic_data API request to generate a variable called appointment_time, you would see it here (both the agent’s inputs and the response variables).

If answered_by_enabled was set to true in the original API request, this field contains one of the following values:

• human: The call was answered by a human.
• voicemail: The call was answered by an answering machine or voicemail.
• unknown: There was not enough audio at the start of the call to make a determination.
• no-answer: The call was not answered.
• null: Not enabled, or still processing the result.

If answered_by_enabled was set to true, then webhooks may take up to a minute to fire after the call ends while the call audio is processed.

Whether the call audio was recorded.

The URL of the recording of the call. Only available if record was set to true in the original API request.

Metadata about the call. This can include information about the client, customer, or any other data you want to include.

This is identical to the metadata that was set in the original API request to send the call.

A short summary of the call based off of the transcript that’s generated when the call ends.

The cost of the call in USD.

Whether Local Dialing was enabled for your account at the time of the call.

Whether the call was ended by Bland’s system or the other end of the line.

• ASSISTANT: The agent ended the call.
• USER: The user ended the call.

Pathways calls will have extra logs here that have much more detailed information about the chosen nodes and internal reasoning throughout the flow.

The provided structure used in the post call analysis. This is the raw skeleton describing the data structure that will be filled in once the call ends.

The data filled in by the post call analysis. This is the raw data that was generated by the analysis schema.

A single string containing all of the text from the call. Excludes system messages and auto-generated data.

An array of phrases spoken during the call.

Each index includes:

• id
• created_at
• text
• user (can be user, assistant, robot, or agent-action)

The status of the call. This is the most up-to-date status of the call, but is only present for calls that have been successfully created.

The corrected duration of the call in seconds. This is the actual length of the call, not the max_duration.