Key Takeaways
Gladly tasks are more than to-do items - they're structured, assignable, customer-linked follow-up actions with due dates and comments. Understanding that model is what makes the API integration actually useful rather than just functional.
The wrapper class pattern isn't ceremony. It's how you keep your Apex code maintainable when the request body has nested objects and your integration needs to evolve over time without breaking everything that calls it.
Error handling in API integrationsis the part everyone writes last and regrets skipping first. Build it in from the start - your future self will appreciate it during the first production incident.
If you've worked with customer service platforms long enough, you know the problem this integration solves.
An appointment gets rescheduled in Salesforce. Somewhere, a Gladly agent needs to know about it, follow up with the customer, and close the loop. Without automation, that's a manual step - someone has to remember to create the task, fill in the right details, assign it correctly. Sometimes they do. Sometimes they don't. Sometimes they do it three days later when the customer has already called back twice.
Apex plus Gladly's task API closes that gap. The follow-up task gets created automatically, assigned correctly, with the right due date and customer context - without anyone having to remember to do it.
That's what this guide walks through. Not a theoretical overview of what's possible, but the actual code pattern that makes it work.
What is a Gladly Task?
Before writing any code, it's worth understanding what a Gladly task actually is - because it's not just a generic to-do item.
A task in Gladly is customer-specific. It lives on a customer's timeline alongside their conversations, emails, and other interactions. It has a body describing what needs to happen, a due date, an assignee (an inbox, a specific agent, or both), and it supports comments. When you create a task through the API, Gladly either attaches it to an existing customer profile or creates a new one if the customer doesn't exist yet.
That last part matters for the integration. You're not just creating abstract tasks - you're creating follow-up work that lives in the context of a real customer relationship. The API reflects that, which is why the request body requires customer identification alongside the task details.
Understanding this model upfront saves a lot of confusion when you're looking at the request schema and wondering why customer identification is required when "you just want to create a task.
How to Create a Gladly Task?
Gladly exposes a POST endpoint for task creation. The request hits the tasks API, carries a JSON body with everything Gladly needs to create and assign the task, and returns a response you can use for error handling and confirmation.
Here's how to build this in Apex, step by step.
- REQUEST BODY SCHEMA: application/json
{
"id": "pOVVdzweSumI4bFxjlT8LA",
"assignee": {
"inboxId": "NFpDZtfqhk2pI6fjaVDlFf",
"agentId": "zGaHXjD4SR-moMR9LbULDa"
},
"body": "Create task to reschedule appointment",
"dueAt": "2020-03-15T06:13:00.125Z",
"customer": {
"emailAddress": "michelle.smith@example.org",
"mobilePhone": "+16505551987"
}
}
id
String <= 50 characters
Specifies the id of the task
assignee
required
object (Assignee)
Inbox and agent assignee for a task
body
required
string <= 10000 characters
Text to describe what task to complete. Constrained HTML Rich Content is supported.
dueAt
required
string <RFC3339>
Time when the task will be due. This must be set to a time in the future.
Customer
required
object (Customer Specification)
Specifies the customer a task belongs to. You must provide exactly one of the values.
- *Create Apex Wrapper Classes for Task Management public class TaskWrapper *
public class TaskWrapper {
public String id;
public AssigneeWrapper assignee;
public String body;
public DateTime dueAt;
public CustomerWrapper customer;
public TaskWrapper(String id, AssigneeWrapper assignee, String body, DateTime dueAt, CustomerWrapper customer) {
this.id = id;
this.assignee = assignee;
this.body = body;
this.dueAt = dueAt;
this.customer = customer;
}
}
public class CustomerWrapper {
public String emailAddress;
public CustomerWrapper(String email) {
this.emailAddress = email;
}
}
public class AssigneeWrapper {
public String inboxId;
public String agentId;
public AssigneeWrapper(String inboxId) {
this.inboxId = inboxId;
}
public AssigneeWrapper(String inboxId, String agentId) {
this.inboxId = inboxId;
this.agentId = agentId;
}
}
- Create a Method to Construct the Request Body with Required Parameters
public static void createTaskToRescheduleAppointment(String customerEmail, String previousDate, String newDate) {
String taskBody =
'<strong>Appointment Rescheduled:</strong> <br>Your appointment has been rescheduled to ' +
newDate +
' from <strong>' +
previousDate+
'</strong>.<br/>';
try {
// Implement logic to get the inbox ID according to your needs.
String inboxId = getInboxId();
AssigneeWrapper assignee = new AssigneeWrapper(inboxId);
CustomerWrapper customer = new CustomerWrapper(customerEmail);
// Either Create a method to get the dueAt date for the new task or use any value directly for the due date according to your requirement.
DateTime dueAt = getRescheduleDueDate();
TaskWrapper task = new TaskWrapper(null, assignee, taskBody, dueAt, customer);
createTask(task);
} catch (Exception e) {
// handle the catch block according to your requirement.
}
}
- Create the createTask Method to Handle the POST Request
public static void createTask(TaskWrapper task) {
if (task != null) {
createTaskOnGladly(task);
}
}
private static HttpResponse createTaskOnGladly(TaskWrapper gladlyTaskWrapper) {
String requestBody = JSON.serialize(gladlyTaskWrapper);
String GLADLY_ENDPOINT = '<organization>.gladly.com/api/v1/tasks';
HttpRequest req = new HttpRequest();
req.setEndpoint(GLADLY_ENDPOINT);
req.setMethod('POST');
req.setHeader('Content-Type', 'application/json;charset=UTF-8');
req.setBody(requestBody);
HttpResponse response = (new Http()).send(req);
// Get the status code of the API request and handle additional features
if (response.getStatusCode() == {Status Code to check}) {
}
return response;
}
Conclusion
What this integration actually buys you is reliability. Tasks get created when they should, with the right information, assigned to the right place - not when someone remembers to create them manually.
The wrapper class pattern keeps the code maintainable as requirements evolve. The method separation keeps concerns clean - one method builds the task, one sends it, and the calling code doesn't need to know about either. When Gladly changes something about its API, or your business rules around inbox assignment change, you know exactly where to go.
The real work after getting this running is the error handling and observability you build around it. What happens when the callout fails? What happens when Gladly returns an unexpected status? How will you know if tasks stop being created? Those questions are worth answering before you put this in production, not after.
About Innostax
Innostax specializes in managed engineering teams and was founded in 2014, and is headquartered in Framingham, Massachusetts. We establish engineering teams with accountability as a priority for both startups and enterprises, helping them achieve consistent software velocity with no customer churn.
Top comments (0)