Pagination is not supported under this resource. Please avoid usage of the page query parameter.
Reservation Instance Subresource
TaskRouter creates a Reservation subresource whenever a Task is reserved for a Worker. TaskRouter will provide the details of this Reservation Instance
subresource in the Assignment Callback HTTP request it makes to your application server.
You have multiple options for handling a Reservation:
Allow your Worker to decide if they can take the Reservation with the
Worker JS SDK
.
The following details the REST API.
Important: If you do not respond with how to handle your Reservation within the TaskReservationTimeout configured on a Workflow, then the Reservation will timeout and the Task will be available for other workers.
The ID of the Workspace that this task is contained within.
TaskSid
The ID of the reserved Task
WorkerSid
The ID of the reserved Worker
WorkerName
Human readable description of the Worker that is reserved
ReservationStatus
The current status of the reservation. See the table below for possible values.
Possible values for ReservationStatus:
Status
Description
accepted
The Reservation was accepted by the Worker.
canceled
The Reservation was canceled because the reservation timeout was reached.
completed
The Reservation was marked as completed.
pending
A Worker has been reserved for this task and TaskRouter is waiting on a reservation response.
rejected
The Reservation was rejected by the Worker.
rescinded
The Reservation was removed from the Worker.
timeout
The Reservation timed out waiting for a response. When this happens, the Task will remain in the queue and TaskRouter will attempt to assign the Task to the next eligible Worker.
wrapping
The Worker has finished the primary work and is finishing additional duties for the Reservation.
Update Reservation
Resource URI
_10
POST /v1/Workspaces/{WorkspaceSid}/Tasks/{TaskSid}/Reservations/{ReservationSid}
To indicate that a Worker has accepted or rejected a Reservation, you make an HTTP POST request to a Reservation instance resource URI.
You can issue a simple Accept or Reject request. You can also issue an Instruction, similar to Responding to an Assignment Callback. We'll detail what parameters need to be provided for each method:
Accepting a reservation means that the worker will work on the task, but you will need to do whatever work is required to connect the details of that task to the worker. You can think of accept as the bare minimum option for task acceptance. For voice tasks, the other methods described below are supersets of accept.
Example
Accept a Reservation
Node.js
Python
C#
Java
Go
PHP
Ruby
twilio-cli
curl
_12
// Download the helper library from https://www.twilio.com/docs/node/install
_12
// Find your Account SID and Auth Token at twilio.com/console
_12
// and set the environment variables. See http://twil.io/secure
accepted. Specifying accepted means the Worker has received the Task and will process it. TaskRouter will no longer consider this task eligible for assignment, and no other Worker will receive this Task. (🏢 not PII )
Reject a Reservation
Example
Reject a Reservation
Node.js
Python
C#
Java
Go
PHP
Ruby
twilio-cli
curl
_12
// Download the helper library from https://www.twilio.com/docs/node/install
_12
// Find your Account SID and Auth Token at twilio.com/console
_12
// and set the environment variables. See http://twil.io/secure
rejected. Specifying rejected means the Worker has refused the assignment and TaskRouter will attempt to assign this Task to the next eligible Worker. (🏢 not PII )
WorkerActivitySid
No
If rejecting a reservation, change the worker that is tied to this reservation to the supplied activity. If not provided, the WorkerPreviousActivitySid on the Reservation will be used. (🏢 not PII )
Important: Tasks are automatically canceled after 1,000 rejections.
Please note: Although Tasks have always been cancelled after 1,000 rejections, the documentation previously incorrectly showed that Tasks are automatically cancelled after 10 rejections. If your solution requires Tasks to be cancelled after 10 rejections instead, please contact our support team for help.
Conference instruction is the recommended way to connect calls between customer and agents. This should be used in almost all cases instead of dequeue or call for call center scenarios
Conference instruction takes care of a lot of the call orchestration which you would otherwise do yourself. For a given call represented by a task in TaskRouter, issuing a conference instruction will:
Call the worker on either the specified
contact_uri
of the worker, or the provided
to
field
Monitor call status to check that the agent has answered the call
Put the agent call into a Conference, named by TaskSid
Monitor that the above has succeeded
Move the caller out of the queue and into the conference
Mark the task as accepted if and only if all the above succeeded, and handle corner cases (such as caller hangs up during this process) gracefully.
Note that conference instruction works out of the box with calls that have been in TaskRouter using the native TaskRouter integration. If you are creating the task manually for a voice call, in order to use conference instruction you must at minimum include in the Task Attributes {"call_sid" : "<callsid>", "to" : "<E.164 to number>"}
Example
Update Conference Instructions
Node.js
Python
C#
Java
Go
PHP
Ruby
twilio-cli
curl
_17
// Download the helper library from https://www.twilio.com/docs/node/install
_17
// Find your Account SID and Auth Token at twilio.com/console
_17
// and set the environment variables. See http://twil.io/secure
Conference instruction uses the Conference Participants API. All values valid for that API can be provided as part of the conference instruction. Note that those parameter names are not replicated here. Please refer to linked documentation for valid values.
Note that the Participant API parameters provided apply to the worker leg of the call, not the customer leg of the call. In particular, note that endConferenceOnExit can only be set for the worker leg. If the customer hangs up if you want the agent call leg to be torn down you should do that via API.
The contact URI of the Worker. A phone number or client ID. Required if the worker's attributes do not include a "contact_uri" property. (📇 PII )
From
No
The caller ID for the call to the worker. Note: This needs to be a verified Twilio number. If you need this to be the original caller number, please contact Support (📇 PII )
PostWorkActivitySid
No
(Deprecated) The activity to move a worker to after executing a conference instruction. Not valid in multi-tasking workspaces. (🏢 not PII )
Timeout
No
The integer number of seconds that Twilio should allow the phone associated with "contact_uri" to ring before assuming there is no answer. Default is 60 seconds, the maximum is 999 seconds. Note, you could set this to a low value, such as 15, to hang up before reaching an answering machine or voicemail. (🏢 not PII )
All other Participant API possible parameters except for the following:caller-idbyocrecording-tracklabelrecording-status-callback-eventconference-recording-status-callback-eventcoachingcall-sid-to-coachcall-reasonspeaker
The contact URI of the Worker. A phone number or client ID. Required if the worker's attributes do not include a "contact_uri" property. (📇 PII )
DequeueFrom
Yes
The caller ID for the call to the worker. Note: This needs to be a verified Twilio number. If you need this to be the original callee number, please contact Support (📇 PII )
DequeuePostWorkActivitySid
No
The activity to move a worker to after executing a dequeue instruction. (🏢 not PII )
DequeueRecord
No
The 'DequeueRecord' attribute lets you record both legs of a call. Set to "record-from-answer" to record the call from answer. Default to "do-not-record" which will not record the call. The RecordingUrl will be sent with DequeueStatusCallbackUrl. (🏢 not PII )
DequeueTimeout
No
The integer number of seconds that Twilio should allow the phone associated with "contact_uri" to ring before assuming there is no answer. Default is 60 seconds, the maximum is 999 seconds. Note, you could set this to a low value, such as 15, to hangup before reaching an answering machine or voicemail. (🏢 not PII )
DequeueStatusCallbackUrl
No
A URL that Twilio will send asynchronous webhook requests to on completed call event. **Note: TaskRouter sends "taskCallSid" as parameter with sid of the call that created the Task. This is very useful in the event a call to worker fails, where you could remove the original call from queue and send to voice mail or enqueue again with new workflow to route to different group of workers. (🏢 not PII )
DequeueStatusCallbackEvent
No
The call progress events that will be sent via webhooks on a worker's call. Available values are initiated, ringing, answered, and completed. If you want to receive multiple events, please provide multiple DequeueStatusCallbackEvent values as individual parameters in the POST request. If no event is specified, defaults to completed. For example to receive webhooks on answered and completed events pass "DequeueStatusCallbackEvent=answered&DequeueStatusCallbackEvent=completed". Please click here for more details. (🏢 not PII )
Note: A property of contact_uri is required on the WorkerAttributes to indicate whom to call. See more information on this here.
The contact URI of the Worker. A phone number or client ID. Required if the worker's attributes do not include a "contact_uri" property. (📇 PII )
CallFrom
Yes
The caller ID to use when placing the outbound call (📇 PII )
CallUrl
Yes
A valid TwiML URI that is executed on the answering Worker's leg. (🏢 not PII )
CallAccept
No
If set to "true", the reservation will be accepted. Otherwise, a separate call to the REST API is responsible for moving the state to accept or reject. (🏢 not PII )
CallRecord
No
The 'CallRecord' attribute lets you record both legs of a call. Set to "record-from-answer" to record the call from answer. Default to "do-not-record" which will not record the call. The RecordingUrl will be sent with DequeueStatusCallbackUrl. (🏢 not PII )
CallTimeout
No
The integer number of seconds that Twilio should allow the phone associated with "contact_uri" to ring before assuming there is no answer. Default is 60 seconds, the maximum is 999 seconds. Note, you could set this to a low value, such as 15, to hangup before reaching an answering machine or voicemail. (🏢 not PII )
CallStatusCallbackUrl
No
A URL that Twilio will send asynchronous webhook requests to on completed call event. **Note: TaskRouter sends "taskCallSid" as parameter with sid of the call that created the Task. This is very useful in the event a call to worker fails, where you could remove the original call from queue and send to voice mail or enqueue again with new workflow to route to different group of workers. (🏢 not PII )
Note: A property of contact_uri is required on the WorkerAttributes to indicate whom to call. See more information on this here.
The Twilio call sid of the call which was parked in the queue(via enqueue for example). (🏢 not PII )
RedirectUrl
Yes
A valid TwiML URI to redirect the call to. (🏢 not PII )
RedirectAccept
No
Boolean. If true, the reservation will be accepted, otherwise, it is your application's responsibility to accept or reject the task at a later point. Defaults to false. (🏢 not PII )