Request Thread Control

The Request Thread Control API allows a Secondary Receiver app to notify the Primary Receiver that it wants control of the chat. The Primary Receiver can then take control of the chat if necessary, then pass control to the Secondary Receiver that sent the request. An optional metadata string may also be sent in the request.

The Primary Receiver may also ignore the request, and do nothing.

How it Works

The flow for using the Request Thread Control API looks like this:

  1. The Secondary Receiver app calls /request_thread_control

  2. The Primary Receiver app receives a messaging_handovers webhook event with the request_thread_control property.

  3. If an app other than the Primary Receiver currently has control of the chat, the Primary Receiver calls /take_thread_control to take control of the chat.

  4. The Primary Receiver calls pass_thread_control to pass control to the Secondary Receiver that called /request_thread_control.

  5. The Secondary Receiver app is given control of the chat, and receives a messaging_handovers with the pass_thread_control property.

Example Request

For complete API details and request properties, see the Request Thread Control Reference.

curl -X POST -H "Content-Type: application/json" -d '{
  "metadata":"additional content that the caller wants to set" 

Example messaging_handovers Event

    "metadata":"additional content that the caller wants to set"

Requesting Thread Control From the Page Inbox

For Messenger experiences that enable live chat via the Page Inbox, the handover protocol allows the Page admin to manually initiate a request thread control messaging_handovers event by moving the conversation from 'Done' to the 'Inbox'.

It is important that the Primary Receiver app honor the request thread control event and pass control to the Page Inbox.