Creating Tasks and Accepting Reservations: Accept a Reservation using Assignment Callback Instructions

You can accept a Reservation automatically by returning an accept assignment instruction in a synchronous HTTP response from your Assignment Callback URL. Earlier, you created a Task and accepted it using the Reservations subresource of the REST API.

This time, you create another Task using the REST API, but your server accepts the Reservation as soon as it is notified, via a synchronous HTTP response.

Before we create the next Task, once again make sure that our Worker Alice is in a non-available Activity state.

Call the Create Task endpoint exposed with server.rb again, or execute the following curl command:

1
ATTRIBUTES_OBJ=$(cat << EOF
2
{
3
  "selected_language": "es"
4
}
5
EOF
6
)
7
curl -X POST "https://taskrouter.twilio.com/v1/Workspaces/WSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/Tasks" \
8
--data-urlencode "Attributes=$ATTRIBUTES_OBJ" \
9
--data-urlencode "WorkflowSid=WWXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
10
-u $TWILIO_API_KEY:$TWILIO_API_SECRET

This time, before bringing Alice online, we need to make changes to our assignment_callback method in our server.rb. Open it and modify the existing code to reflect the following:

server.rb

1
require 'rubygems'
2
require 'twilio-ruby'
3
require 'sinatra'
4
require 'json'
5

6
set :port, 8080
7

8
# Find your Account SID: https://www.twilio.com/console
9
# Create API keys: https://www.twilio.com/docs/iam/api-keys/keys-in-console
10
account_sid = '{{ account_sid }}'
11
api_key = '{{ api_key }}'
12
api_secret = '{{ api_secret }}'
13
workspace_sid = '{{ workspace_sid }}'
14
workflow_sid = '{{ workflow_sid }}'
15

16
client = Twilio::REST::Client.new(api_key, api_secret, account_sid)
17

18
post '/assignment_callback' do
19
# Respond to assignment callbacks with accept instruction
20
content_type :json
21
{"instruction": "accept"}.to_json
22
end
23

24
get '/create-task' do
25
# Create a task
26
task = client.taskrouter.workspaces(workspace_sid)
27
.tasks
28
.create(
29
attributes: {
30
'selected_language' => 'es'
31
}.to_json,
32
workflow_sid: workflow_sid
33
)
34
task.attributes
35
end
36

37
get '/accept_reservation' do
38
# Accept a Reservation
39
task_sid = params[:task_sid]
40
reservation_sid = params[:reservation_sid]
41

42
reservation = client.taskrouter.workspaces(workspace_sid)
43
.tasks(task_sid)
44
.reservations(reservation_sid)
45
.update(reservation_status: 'accepted')
46
reservation.worker_name
47
end

Instead of returning an empty JSON document as before, we've included an 'assignment instruction' in our response. The 'accept' assignment instruction tells TaskRouter to automatically accept the Reservation and assign the Task to the Worker it has been reserved for.

To kick this process off, we need to transition Alice to an available Activity. With your Workspace open in the TaskRouter console, click 'Workers' then click to edit Alice and set her Activity to 'Idle'.

Now, click 'Tasks' in the main navigation and you should see that the Task has an Assignment Status of 'assigned':

Expand image

What actually happened is that Alice was reserved for a very short period of time. TaskRouter made a request to your web server at the Assignment Callback URL, and your server told TaskRouter to accept the Reservation. At that point, Alice's Activity transitioned to the 'Assignment Activity' of the TaskQueue that assigned the Task, as it did in the previous step.

Expand image

And that's that. We created another Task using the REST API, accepted it via an assignment instruction at our Workflow's Assignment Callback URL and saw that this immediately accepted the Reservation for our Worker.

Onward! Next, we'll learn about shortcuts to create Tasks originating from Twilio phone calls.

Part 3: Create Tasks from Phone Calls using TwiML »