Gladly Connector

Connect Gladly so Applied can work with Gladly customers, conversations, inboxes, and replies during support workflows.

Use this Connector when your support team uses Gladly and wants Applied to keep conversation context aligned during escalation, assignment, and reply flows.

Common use cases

Sync Gladly customer and conversation context.
Reply to supported Gladly conversation items.
Replay Applied webchat transcripts during Custom Channel escalations.
Restrict ingestion to specific Gladly inboxes.
Route escalations to a configured Gladly inbox.
Sync Gladly conversation assignment, status, close, reopen, and contact session events from webhooks.
Deliver email from a workflow’s Send Email node through Gladly instead of Applied email.

Before you begin

Before connecting Gladly, make sure:

You know the Gladly organization subdomain.
You know whether to connect production or sandbox.
A Gladly administrator can create or update the integration user.
The Gladly user for setup has API User permission and keeps the Agent role.
Your team knows which inboxes Applied should ingest from or escalate to.
You have a test conversation available for validation.
You have the Applied webhook URL, webhook username, webhook password, and X-Agent-Id header value from Applied support if you plan to enable webhooks.

If you use the Gladly sandbox, Applied connects to https://<organization>.gladly.qa. Production uses https://<organization>.gladly.com.

Gladly API tokens and webhooks are tied to the Gladly user and environment where they are created. Use separate tokens and webhooks for sandbox and production.

Required Gladly permissions

Create a dedicated Gladly user for Applied when possible. This user should have:

API User permission, so it can create API tokens and use the Gladly REST API.
Agent role, so the token remains attached to an active Gladly agent profile.
Access to the inboxes and conversations Applied should read, reply to, or route escalations into.

To create the webhook, use a Gladly user that can access Settings > App Developer Tools > Webhooks.

Get a Gladly API token

Gladly API tokens are created from Gladly settings.

In Gladly, open Settings.
Under App Developer Tools, go to API tokens.
Click Create Token.
Name the token, such as Applied Labs.
Copy the token.

Use the email address for the Gladly user whose token you created. Applied uses Basic auth with that email and token.

Configure Gladly access

Gladly grants API access through the user. Keep the user as an agent and enable the API User permission.

Gladly API tokens can perform API requests for that account, so use a dedicated Gladly user when possible and keep the token private.

If you want Applied to listen only to selected inboxes, collect the Gladly inbox IDs and enter them as the ingestion inbox IDs. If you want escalations to move to a specific inbox, collect that inbox ID separately.

Connect Gladly in Applied

Open Connectors.
Click New.
Choose Gladly.
Enter the Gladly subdomain.
Enter the Gladly API user email.
Turn on sandbox mode only for a Gladly sandbox.
Optionally enter AI ingestion inbox IDs.
Optionally enter one escalation inbox ID.
Paste the Gladly API token into the API token field.
Create the connection.

Enter multiple ingestion inbox IDs as a comma-separated list.

Send workflow email through Gladly

The Send Email flow node uses Applied email delivery by default. To deliver that node’s message through Gladly instead:

Add or open a Send Email node in the flow editor.
Set Delivery method to Connected integration.
Choose a sender address that is configured for email in Gladly.

Gladly currently supports one recipient and does not support CC or BCC for this operation. Applied still creates and threads the message in its local conversation even though Gladly records this outbound communication outside a Gladly conversation.

Escalate Applied webchat through a Gladly Custom Channel

Custom Channels let an Applied-owned webchat become a routable Gladly conversation when a customer needs a human agent. This feature must be enabled for your Gladly organization before Applied can use it.

In Gladly:

Ask your Gladly administrator or Gladly Support to enable Custom Channels.
Create a Custom Channel and an Entry Point.
Configure the Entry Point’s default inbox or routing rules.
Open the Entry Point’s integration data and copy its Custom Channel ID and exact Entry Point address.
Confirm the agents who will reply on this channel have API User permission.

In the Gladly resource in Applied, enter:

Custom channel ID
Entry point address

Both values are required only when Applied-owned webchat conversations should escalate into Gladly. They are not API credentials. Keep the Gladly API token in the Connector credential field.

For an existing Gladly connection where these fields are not shown in the resource settings, ask an Applied administrator to add both values to the resource metadata. The update must preserve the resource’s other metadata.

Applied sends each visible webchat turn to the configured Entry Point in chronological order, reads each created Gladly conversation item, and links the Applied conversation to the returned Gladly conversation. Each imported turn includes its speaker name in the message text because Gladly’s Custom Channel ingestion API records imported items as customer-originated. Applied does not add a transcript note. Later customer messages stay on that Custom Channel thread.

Configure Gladly webhooks

Gladly webhooks let Applied receive conversation activity as it happens. Create the webhook after the Gladly Connector is created in Applied, because the webhook URL may include the Applied integration ID.

Webhook endpoint

Use the webhook URL provided by Applied. It usually has this shape:


https://core.appliedlabs.ai/v1/integrations/gladly/event/?integration_id=<applied-integration-id>

Use the matching URL for your Applied environment if you are connecting a sandbox or staging workspace.

Webhook authentication

In Gladly, configure the webhook with:

Username: the webhook username provided by Applied.
Password: the webhook password provided by Applied.
HTTP header: add X-Agent-Id with the value provided by Applied.

Do not reuse the Gladly API token as the webhook password unless Applied explicitly tells you to. The API token is for Applied calling Gladly. The webhook username, password, and X-Agent-Id header are for Gladly calling Applied.

Webhook events

Subscribe the Gladly webhook to these events:

CONTACT/MESSAGE_RECEIVED
CONTACT/MESSAGE_SENT
CONTACT/STARTED
CONTACT/ENDED
CONVERSATION/CREATED
CONVERSATION/CLOSED
CONVERSATION/REOPENED
CONVERSATION_ASSIGNEE/UPDATED
CONVERSATION_STATUS/UPDATED

If you use Custom Channels for Applied webchat escalation, also subscribe to:

CUSTOM_CHANNEL/MESSAGE_SENT

This event carries human replies from Gladly back to the original Applied webchat. Keep CONVERSATION/CLOSED enabled so closing the conversation in Gladly also updates Applied.

If your Gladly environment exposes the message-level event name, also subscribe to:

MESSAGE/RECEIVED

Gladly sends PING when creating or enabling a webhook to verify the endpoint. You do not need to add PING manually if Gladly sends it automatically during setup.

Create the webhook in Gladly

In Gladly, open Settings.
Under App Developer Tools, click Webhooks.
Click Create Webhook.
Enter a name, such as Applied Labs.
Paste the Applied webhook URL.
Add the events listed above.
Enter the webhook username and password from Applied.
Add the X-Agent-Id HTTP header from Applied.
Turn on Enabled.
Save the webhook.

Gladly expects the endpoint to respond quickly. Applied acknowledges webhook requests immediately and processes authenticated events in the background.

Validate the connection

After setup:

Look up a test Gladly customer or conversation.
Confirm Applied can read the conversation items.
Send a test reply on a non-production conversation if replies are enabled.
If inbox filters are configured, confirm conversations in other inboxes are ignored.
If escalation inbox routing is configured, confirm a test escalation lands in the expected inbox.
If webhooks are configured, send a new customer message in Gladly and confirm it appears in Applied.
Close and reopen the test conversation in Gladly and confirm Applied updates the conversation state.
If Custom Channels are configured, escalate an Applied webchat, reply from Gladly, and confirm the reply appears in the same Applied webchat.

Common issues

Authentication fails

Confirm the email matches the Gladly user that owns the token and that the user has API User permission.

Applied connects to the wrong Gladly environment

Check the sandbox toggle. Sandbox uses .gladly.qa; production uses .gladly.com.

Conversations are ignored

Review the ingestion inbox ID list. When configured, Applied ingests only from the listed inboxes.

Webhook setup cannot be saved

Confirm the webhook URL is correct and reachable over HTTPS. Gladly verifies the endpoint with a ping when a webhook is created or enabled.

Webhook events stop arriving

Check Gladly webhook logs. Gladly can deactivate a webhook after repeated delivery failures. Resolve the error in the webhook log, then reactivate the webhook.

If Gladly shows successful deliveries but events do not appear in Applied, confirm the webhook username, password, and X-Agent-Id header match the values from Applied.

Replies are not sent from Applied

Confirm the Gladly conversation is open and assigned in a way that allows Applied to reply. Gladly does not allow replies to closed conversations, and Applied does not auto-reply on voice or voicemail contacts.

Applied webchat does not create a Gladly conversation

Confirm Custom Channels are enabled for your Gladly organization. Then verify that the Custom Channel ID and Entry Point address in Applied exactly match the values shown in the Gladly Entry Point’s integration data.

If the conversation is created but agent replies do not return to Applied, confirm the webhook subscribes to CUSTOM_CHANNEL/MESSAGE_SENT.