Menu

Rate this page:

Thanks for rating this page!

We are always striving to improve our documentation quality, and your feedback is valuable to us. How could this documentation serve you better?

REST API: Reservations

Reservation Instance Subresource

TaskRouter creates a Reservation subresource whenever a Task is reserved for a 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:

  1. Respond to the Assignment Callback with an Assignment Instruction.
  2. Call the REST API with how to handle it.
  3. 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.

Actions


Retrieve a Reservation

Resource URI

GET /v1/Workspaces/{WorkspaceSid}/Tasks/{TaskSid}/Reservations/{ReservationSid}

Returns the single reservation resource identified by {ReservationSid}.

Example
        
        
        
        

        Resource Properties

        A Reservation has the following properties.

        Field Description
        Sid The unique ID of this Reservation.
        AccountSid The ID of the Account that owns this Task
        WorkspaceSid 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
        pending A Worker has been reserved for this task and TaskRouter is waiting on a reservation response.
        accepted The Reservation was accepted by the Worker.
        rejected The Reservation was rejected by 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.

        Update Reservation

        Resource URI

        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:

        1. Accept a Reservation
        2. Reject a Reservation
        3. issue a Conference Instruction
        4. Issue a Dequeue Instruction
        5. Issue a Call Instruction
        6. Redirect an active phone call to TwiML document

        Accept a Reservation

        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

              
              
              
              

              POST Parameters

              Field Required? Description
              ReservationStatus Yes 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 )
                    
                    
                    
                    

                    POST Parameters

                    Field Required? Description
                    ReservationStatus Yes 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 10 rejections.

                    Please see Manually accepting or rejecting a reservation for more information.

                    Conference Instruction

                    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

                          
                          
                          
                          

                          POST Parameters

                          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.

                          Field Required? Description
                          Instruction Yes Conference (🏢 not PII )
                          To No 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 callee 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 No See linked documentation

                          Note: A property of contact_uri is required on the WorkerAttributes to indicate whom to call. See more information on this here.

                          Dequeue Instruction

                          In most situations we would recommend you use Conference Instruction instead of dequeue

                                
                                
                                
                                

                                POST Parameters

                                Field Required? Description
                                Instruction Yes Dequeue (🏢 not PII )
                                DequeueTo No 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.

                                Please see issuing a Dequeue Instruction for more information.

                                      
                                      
                                      
                                      

                                      POST Parameters

                                      Field Required? Description
                                      Instruction Yes Call (🏢 not PII )
                                      CallTo No 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.

                                      Please see issuing a Call Instruction for more information.

                                            
                                            
                                            
                                            

                                            POST Parameters

                                            Field Required? Description
                                            Instruction Yes Redirect (🏢 not PII )
                                            RedirectCallSid Yes 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 )

                                            Please see Redirect a call to a new TwiML document for more information.

                                            Reservations List Resource

                                            Resource URI

                                            GET /v1/Workspaces/{WorkspaceSid}/Tasks/{TaskSid}/Reservations
                                            

                                            Returns a representation of all the list of Reservations waiting for a Task identified by {TaskSid}.

                                            Example
                                                  
                                                  
                                                  
                                                  

                                                  List Filters

                                                  Field Description
                                                  WorkerSid Returns the list of reservations for a task for a specified worker
                                                  ReservationStatus Returns the list of reservations for a task with a specified ReservationStatus
                                                  Rate this page:

                                                  Need some help?

                                                  We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.