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
Reference | Type | Description |
---|---|---|
auth | Hash | •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. |
data | Hash | •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. |
meta | Hash | A hash of meta fields containing accessory information that is useful for the bridge to fulfil this request |
meta
Reference | Type | Description |
---|---|---|
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
Reference | Type | Description |
---|---|---|
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 IDin 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.
Updated about 1 year ago