Action Executor

Overview

The action executor allows building actions that can be triggered via Talkdesk's automations system.

Talkdesk® will execute a configured action on the bridge when a trigger of an automation where that action takes part occurs on the system. Actions can also be executed from a request of a user with manually input data.

For an action executor to be triggered by Talkdesk, the bridge proving its endpoint needs to follow a strict contract:

•Only POST requests are allowed.
•When using a custom authentication type, the associated fields will be sent in the request body inside the auth field.

Request

POST https://example.com/new_action

ReferenceTypeDescription
authHash•A hash of authentication fields containing a user's credentials within the external service.
•The keys correspond to the fields asked by the integration when configuring it with Talkdesk.
dataHash•A hash of data fields and respective values the bridge needs to execute the action in the external service.
•The keys correspond to the fields asked by the integration through the action configuration.
metaHashA hash of meta fields containing accessory information that is useful for the bridge to fulfil this request

meta

ReferenceTypeDescription
meta.contact_external_id•String.
•Optional.
For contacts that were previously synchronized through the bridge, if this action is executed in the scope of a contact, Talkdesk sends its ID in the external service for direct identification
meta.agent_external_id•String.
•Optional.
For agents that were previously synchronized through the bridge, this field will appear if the agent that executed the action is present in Talkdesk

Steps

1 - Use the auth fields to authenticate on behalf of the user within the external service. Talkdesk makes sure that all mandatory fields are filled as expected.

2 - Use contextual information passed as a meta field (such as the contact ID in the external service) to correctly associate actions to the entities in the external service. Also, if possible, assigning the given agent to the executed action.

3 - Build a request based on the data parameters and send it to the external service.

4 - It will return a 201 HTTP status code response if it succeeds, a 400 if otherwise.

Sample Request

{
    "auth": {
        "username": "[email protected]",
        "password": "605b32dd"
    },
    "meta": {
        "contact_external_id": "1",
        "agent_external_id": "2"
    },
    "data": {
        "subject": "Call missed in Talkdesk",
        "description": "A call from Jane Doe was missed."
    }
}

Response

POST https://example.com/new_action

ReferenceTypeDescription
message•String.
•Optional.
A generic message describing the execution result. E.g.: Case successfully created, Case creation failed, etc.
external_id•String.
•Optional.
•For actions that create a resource in the external service (other than contact).
external_id represents the resource ID
in the external service.
contact_external_id•String.
•Optional.
•For actions that create a contact in the external service.
contact_external_id represents contact ID in the external service.
contact_external_type•String.
•Optional.
•For actions that create a contact in the external service.
contact_external_type represents contact type in the external service.

Sample Response

{
	“message”: “Case successfully created”,
	“contact_external_id”: “7d97925a-864e-414d-9cc1-a09dd487d3e6”,
	“contact_external_type”: “lead”,
	“contact_external_url”: “https://my.site.com/contact/123”
}

🚧

Troubleshooting

If you have questions or technical issues, please open a ticket using this form.