Ellipse Gradient for Header

Gladly Integration Guide

Integrate Gladly customer-service data with enterprise systems through REST APIs, selected webhook notifications, and Martini workflows.

Gladly integration options at a glance

Gladly provides REST APIs for accessing customer-service resources such as Customers, Conversations, Interactions, Agents, Teams, and Topics. Selected platform events can also be delivered through webhook-style notifications, although coverage varies by event and account configuration. A generally available bulk API, public GraphQL API, SOAP API, direct database access, and general-purpose file API were not confirmed. Martini can securely consume Gladly REST APIs, receive selected notifications through an exposed API or workflow trigger, paginate and checkpoint scheduled synchronizations, transform payloads, and route data to enterprise applications, databases, or analytics platforms.

Integration pointSupported by Gladly?Common use casesHow Martini supports it
REST APIsYesRetrieve Customers, Conversations, Interactions, Agents, Teams, and Topics, and perform resource-specific reads or writes where the Gladly account and endpoint permit them.Martini can consume Gladly REST APIs from workflows, paginate collections, map responses, apply business rules, and expose a normalized API for downstream applications.
Webhooks and outbound callbacksLimitedReceive notifications for selected Gladly platform events. Coverage depends on the event type and account configuration and should not be assumed for every object change.Martini can expose an API or use a workflow trigger to receive, validate, persist, transform, and asynchronously route Gladly notifications.
AuthenticationYesUse organization- or account-issued API credentials for programmatic access to Gladly resources over HTTPS, subject to tenant permissions.Martini can store Gladly credentials in environment-specific secrets and apply the authorization configuration required by each target endpoint.
Pagination and incremental synchronizationYesRetrieve larger collections through paginated REST requests and synchronize changes using a confirmed timestamp, cursor, or last-seen identifier where the endpoint supports it.Martini workflows can maintain checkpoints, control concurrency, throttle requests, and resume from the last successful position.
Bulk or batch APIsNot confirmedA generally available Gladly bulk or asynchronous batch API was not confirmed. Large transfers should use paginated, rate-aware REST workflows unless account documentation specifies otherwise.Martini can orchestrate paginated requests and scheduled processing but should not assume a Gladly bulk endpoint exists.
File or attachment APIsNot confirmedA general-purpose Gladly file import, export, or attachment API was not confirmed. Conversation media requirements require endpoint-specific verification.Martini can process files when Gladly exposes a supported endpoint or documented export, but no Gladly file capability should be assumed.
GraphQL APIsNot confirmedNo public Gladly GraphQL API was confirmed. Gladly integrations should use documented REST APIs unless an account-specific GraphQL service is provided.Martini can consume GraphQL generally, but this integration should not depend on GraphQL without Gladly confirmation.
SOAP APIsNoNo public Gladly SOAP API was confirmed for new integrations.Martini should use Gladly REST APIs and selected webhook notifications instead of designing against SOAP.

How Gladly exposes data and business events

Gladly REST APIs

Gladly provides REST APIs for customer-service resources, including Customers, Conversations, Interactions, Agents, Teams, and Topics. Supported operations and filters vary by resource, so endpoint permissions and field behavior should be confirmed for the target account.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with environment-managed Gladly credentials, calls the relevant resource endpoint, follows pagination, maps the response into a canonical model, applies privacy and business rules, and writes to the target system. Checkpoints and stable Gladly identifiers support incremental synchronization and reconciliation.

Implementation sequence

Authenticate with the Gladly API using environment-specific credentials
Call the required Gladly resource endpoint
Retrieve all required pages or continue from the synchronization checkpoint
Validate and map the response into the canonical model
Apply privacy, routing, and business rules
Upsert the result in the target system using a stable Gladly identifier

Gladly webhooks and event notifications

Gladly supports webhook-style notifications for selected platform events. Notification coverage is partial and event-specific, so a webhook should not be treated as a universal replacement for REST reconciliation.

Martini implementation pattern

Martini implementation pattern: expose a controlled Martini API or workflow trigger, validate the incoming Gladly request according to the account’s documented security model, acknowledge promptly, and process the notification asynchronously. The workflow can retrieve the current Customer, Conversation, or Interaction before routing it to another application, while a scheduled reconciliation flow covers events that are not delivered.

Implementation sequence

Receive the selected Gladly event notification
Validate the request and preserve the original payload
Acknowledge the notification promptly
Retrieve the current Gladly object when the event payload is incomplete
Apply routing, deduplication, and business rules
Process the notification asynchronously and record the outcome

Scheduled paginated synchronization

Because a generally available Gladly bulk API was not confirmed and webhook coverage is selected rather than universal, scheduled REST synchronization is an important reliability pattern for larger or completeness-sensitive data flows.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that reads a persisted cursor, timestamp, or last-seen identifier, retrieves paginated Gladly collections, throttles requests, transforms records, and commits the checkpoint only after downstream processing succeeds. Failed pages or records remain available for bounded retry and replay.

Implementation sequence

Start the synchronization workflow on a defined schedule
Load the last successful checkpoint
Retrieve the next Gladly page with rate-aware controls
Map and validate each Customer, Conversation, or Interaction
Write successful results and capture rejected records
Commit the checkpoint after downstream processing completes

Common Gladly integration patterns

Pattern 1: Sync Gladly Customers to Salesforce

When to use this pattern

Use this pattern when customer-service profiles must remain aligned with CRM account and contact data. A scheduled workflow can retrieve changed Customers, resolve matching keys, and update Salesforce without repeatedly transferring the full Gladly dataset.

Integration direction
Gladly
Martini
Salesforce
Example Mapping
Gladly FieldCanonical FieldTarget Field
Gladly customer identifiercustomerIdSalesforce External ID
Customer namefullNameContact Name
Customer emailemailContact Email
Customer contact detailscontactMethodsContact Phone
Martini implementation pattern

A scheduler starts a paginated Gladly REST workflow using a stored checkpoint. Martini normalizes customer fields, validates required contact data, applies privacy rules, resolves the Salesforce external ID, and performs an idempotent upsert. Rate-limit responses receive bounded retries, while invalid records are routed to an error process with the source identifier preserved.

Martini capabilities used
  • workflows
  • API consumption
  • scheduling
  • data mapping
  • business rules
  • error handling

Pattern 2: Send Gladly Conversations and Interactions to Snowflake

When to use this pattern

Use this pattern when analytics teams need normalized customer-service activity rather than application-specific conversation payloads. It is suitable for scheduled ingestion where Gladly does not provide a confirmed bulk API.

Integration direction
Gladly
Martini
Snowflake
Example Mapping
Gladly FieldCanonical FieldTarget Field
Conversation identifierconversationIdCONVERSATION_ID
Interaction timestampoccurredAtOCCURRED_AT
Interaction channelchannelCHANNEL
Agent identifieragentIdAGENT_ID
Martini implementation pattern

Martini retrieves paginated Conversations and associated Interactions, flattens nested structures, converts timestamps, associates Customers and Agents, and masks content that is not required for analytics. The workflow writes curated data to the target ingestion process, keeps Gladly IDs for traceability, and retries transient failures without advancing the checkpoint prematurely.

Martini capabilities used
  • workflows
  • API consumption
  • scheduled synchronization
  • data transformation
  • data mapping
  • error handling

Pattern 3: Route selected Gladly events to ServiceNow

When to use this pattern

Use this pattern when selected customer-service events or escalations must create or update enterprise service-management work. Because Gladly webhook coverage is partial, the design should include REST reconciliation for important objects or events that are not notified.

Integration direction
Gladly
Martini
ServiceNow
Example Mapping
Gladly FieldCanonical FieldTarget Field
Conversation identifiersourceConversationIdCorrelation ID
Conversation subject or summarysummaryShort description
Topic classificationclassificationCategory
Customer identifiercustomerIdCaller reference
Martini implementation pattern

A Martini API receives the selected Gladly notification, validates and records the payload, and acknowledges promptly. An asynchronous workflow retrieves the current Conversation when needed, applies Topic-based escalation rules, creates or updates a ServiceNow incident, and stores the cross-system correlation ID. Duplicate events are suppressed and failed writes are retried or routed for review.

Martini capabilities used
  • API exposure
  • workflow triggers
  • asynchronous execution
  • data mapping
  • business rules
  • idempotency
  • error handling

Pattern 4: Expose a normalized Gladly API façade

When to use this pattern

Use this pattern when downstream applications should access approved Gladly customer-service data without depending directly on Gladly’s resource model, credentials, or endpoint-specific behavior.

Integration direction
Client application
Martini
Gladly
Example Mapping
Gladly FieldCanonical FieldTarget Field
Gladly CustomercustomerNormalized customer response
Gladly ConversationconversationService interaction response
Gladly InteractionactivityActivity collection
Gladly identifiersourceIdExternal reference
Martini implementation pattern

Martini exposes a controlled REST API that authenticates callers, validates request parameters, invokes the required Gladly REST resources, and maps responses into a stable canonical contract. The façade can enforce field filtering, apply authorization and privacy rules, and translate upstream errors without exposing Gladly credentials or internal endpoint details.

Martini capabilities used
  • API exposure
  • API consumption
  • authentication and authorization
  • data mapping
  • business rules
  • error handling

Applications commonly integrated with Gladly

Gladly customer-service data can be connected to adjacent CRM, commerce, enterprise service, analytics, and business applications through its REST APIs and selected webhook notifications. These are standards-based integration patterns rather than confirmed Gladly-native packaged integrations, so endpoint coverage and object-level permissions should be validated for each implementation.

Application Scenario Direction Martini Pattern
Salesforce Synchronize Gladly Customers, service activity, and conversation history with Salesforce account and contact data. Gladly → Martini → Salesforce A scheduled Martini workflow retrieves changed Gladly Customers and relevant Conversations, maps stable Gladly identifiers into Salesforce account or contact keys, performs idempotent upserts, and routes validation or API failures for replay.
Shopify Give support processes access to commerce and order context, and associate Gladly conversations with Shopify customers or orders. Shopify → Martini → Gladly Martini can receive or schedule Shopify data retrieval, normalize customer and order identifiers, and call the relevant Gladly REST endpoints where the account permits the required updates. Conversation and customer responses can also be sent back to Shopify through its APIs.
NetSuite Exchange customer, order, fulfillment, or account context with Gladly customer-service activity. NetSuite → Martini → Gladly A Martini workflow retrieves approved NetSuite business data, applies account and privacy rules, maps it to Gladly-supported resources, and records correlation identifiers. A reverse flow can synchronize Gladly Customers or Conversations into NetSuite where supported by both APIs.
Zendesk Support a customer-service platform transition, consolidation, or selective synchronization of support history. Gladly → Martini → Zendesk Martini paginates Gladly Conversations and Interactions, flattens channel and participant data, maps it to Zendesk objects, preserves source identifiers, and uses checkpoints plus idempotent writes to support migration or ongoing exchange.
ServiceNow Send customer-service escalations or selected Gladly activity into enterprise service-management workflows. Gladly → Martini → ServiceNow A Gladly webhook or scheduled REST workflow validates the source event, applies routing rules based on Topics or conversation attributes, creates or updates a ServiceNow incident, and stores the cross-system correlation ID for status tracking.
Snowflake Centralize Conversations, Interactions, customer-service metrics, and selected customer attributes for analytics and reporting. Gladly → Martini → Snowflake Martini retrieves paginated Gladly resources, normalizes nested conversations and interactions, masks unnecessary personal data, converts timestamps, and writes curated rows or files to a Snowflake ingestion process with checkpoint and replay metadata.
Workday Align selected organizational or employee information where Gladly Agents and Teams require enterprise identity or organizational context. Workday → Martini → Gladly A controlled Martini workflow retrieves approved Workday organizational data, maps agent or team attributes to Gladly-supported fields where available, validates permissions, and records rejected mappings without assuming that every Gladly resource is writable.
Jira Create engineering or product issues from escalated customer conversations and optionally return issue status to service teams. Gladly → Martini → Jira Martini receives a selected Gladly event or runs a reconciliation workflow, extracts the conversation context, applies escalation rules, creates a Jira issue with a stable Gladly reference, and optionally updates the downstream status through a controlled reverse workflow.

How to build a Gladly integration in Martini

Objective

Establish the Gladly API connection using tenant-specific credentials and environment configuration without embedding secrets in workflow definitions.

Instructions in Martini

  • Confirm the Gladly API resources, permissions, and authorization header requirements for the account
  • Store credentials and endpoint configuration in Martini environment-specific secrets
  • Use HTTPS for all Gladly API calls
  • Configure target-system credentials separately from Gladly credentials

Objective

Select an event-driven or scheduled entry point based on the completeness and latency requirements of the integration.

Instructions in Martini

  • Use a Martini API or workflow trigger for selected Gladly webhook notifications
  • Use a scheduler for reconciliation and incremental synchronization
  • Do not assume webhook coverage for every Customer, Conversation, or Interaction change
  • Define the checkpoint or event-deduplication strategy before processing data

Objective

Receive event payloads or retrieve the current Gladly resource state through the documented REST APIs.

Instructions in Martini

  • Validate incoming notification payloads before processing
  • Call the relevant Gladly endpoint for Customers, Conversations, Interactions, Agents, Teams, or Topics
  • Handle pagination and endpoint-specific filters explicitly
  • Throttle requests and respond appropriately to rate-limit conditions

Objective

Coordinate retrieval, enrichment, transformation, target writes, and reconciliation in a maintainable Martini workflow.

Instructions in Martini

  • Separate notification intake from longer asynchronous processing when appropriate
  • Retrieve related Gladly objects only when required by the target model
  • Apply checkpoints after successful downstream processing
  • Keep source identifiers and correlation identifiers throughout the workflow

Objective

Convert Gladly resource structures into the canonical and target schemas required by downstream applications.

Instructions in Martini

  • Flatten nested Conversations and Interactions where analytics or target APIs require it
  • Normalize timestamps, channels, identifiers, and contact fields
  • Mask or omit sensitive customer content that is not needed by the target
  • Preserve unknown fields only when the destination and privacy rules allow it

Objective

Use customer-service classifications and organizational data to control routing, filtering, enrichment, and escalation.

Instructions in Martini

  • Use Topics, Teams, Agents, and conversation attributes as routing inputs where appropriate
  • Validate required fields before writing to downstream systems
  • Apply idempotency keys based on stable Gladly identifiers
  • Route validation failures and unresolved references to an operational review process

Common Gladly data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
CustomersSynchronize customer profiles and contact information with CRM, commerce, analytics, or enterprise service systems.Salesforce, Shopify, NetSuite, Snowflake, SQL databasesMartini retrieves Customers through the REST API, normalizes contact fields, applies privacy rules, preserves Gladly identifiers, and performs idempotent downstream upserts.
ConversationsShare customer-service conversations, channel context, status, and history with CRM, service-management, migration, or analytics platforms.Salesforce, Zendesk, ServiceNow, Snowflake, JiraMartini retrieves and paginates Conversations, associates them with Customers and Agents, applies routing and data-minimization rules, and writes normalized representations to target systems.
InteractionsTransfer individual messages, calls, or other communication activities for service history, analytics, escalation, or migration.Zendesk, Salesforce, Snowflake, SQL databasesMartini retrieves Interactions where permitted, flattens nested structures, converts timestamps and channels, masks unnecessary content, and links each item to its Gladly Conversation.
AgentsMap service representatives to ownership, routing, reporting, identity, or organizational context.Salesforce, Workday, Snowflake, ServiceNowMartini retrieves approved Agent attributes, applies field-level access rules, and maps stable agent identifiers to downstream ownership or reporting fields.
TeamsRepresent organizational groupings for routing, reporting, workforce alignment, and service ownership.Workday, Salesforce, ServiceNow, SnowflakeMartini synchronizes Teams through controlled workflows, validates organizational mappings, and records unresolved references rather than forcing incomplete relationships.
TopicsClassify customer-service activity for routing, escalation, reporting, and analytics.ServiceNow, Jira, Salesforce, SnowflakeMartini uses Topics as business-rule inputs, maps them to target classifications, and routes or enriches Conversations and Interactions accordingly.

Authentication and security considerations

Tenant-specific credentials

Gladly API access uses credentials issued for an organization or account. The exact authorization header, token format, and permissions should be confirmed against the Gladly documentation for the target tenant and endpoint.

Secure environment configuration

Martini should store Gladly credentials and endpoint settings in environment-specific secrets rather than embedding them in workflows. All API traffic should use HTTPS.

Webhook validation

Martini webhook endpoints should validate incoming Gladly requests according to the security options documented for the configured Gladly event mechanism. Access should be restricted to the intended integration surface.

Customer data protection

  • Minimize copied customer and conversation fields.
  • Mask sensitive content when it is not required downstream.
  • Restrict access to conversation and interaction data.
  • Apply retention, deletion, and audit rules consistently across systems.

Operational considerations for Gladly integrations

Pagination and rate limits

Treat Gladly collection endpoints as paginated unless the specific endpoint states otherwise. Confirm rate-limit policies, throttle requests, handle HTTP 429 responses, and prefer incremental synchronization over repeated full retrievals.

Webhooks and reconciliation

Gladly webhook coverage is selected rather than universal. A scheduled REST reconciliation workflow may be needed to identify changes that are not delivered through notifications.

Idempotency and retries

Use stable Gladly object or event identifiers for deterministic upserts. Apply bounded retries for transient failures and prevent checkpoint advancement until downstream processing succeeds.

Schema and testing

Resource fields and supported operations may vary. Isolate Gladly mappings, validate payloads before writes, monitor schema changes, and test representative Customers, Conversations, Interactions, Agents, Teams, and Topics.

Privacy and observability

Preserve correlation identifiers, receipt times, and processing outcomes for troubleshooting while avoiding unnecessary duplication of customer communication content. Monitor workflow logs and rejected records.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate more than API calls

Martini combines Gladly REST consumption, webhook intake, scheduling, transformation, business rules, target writes, and error handling in maintainable workflows rather than scattering behavior across scripts.

Separate vendor and downstream models

Martini can map Gladly Customers, Conversations, Interactions, Agents, Teams, and Topics into canonical and target-specific schemas. This reduces direct coupling between Gladly’s resource model and every downstream application.

Support reliable processing

Checkpoints, pagination, idempotent writes, bounded retries, asynchronous processing, and reconciliation workflows help integrations remain reliable when notifications are incomplete or APIs experience transient failures.

Expose controlled APIs

Martini can provide a normalized API façade so applications can access approved Gladly data without holding Gladly credentials or depending on endpoint-specific details.

Frequently asked questions

How can Gladly be integrated with enterprise systems?

Gladly can be integrated through its REST APIs and selected webhook-style event notifications. Enterprise workflows can retrieve Customers, Conversations, Interactions, Agents, Teams, and Topics, synchronize them on a schedule, or react to supported events. Large transfers should use paginated, rate-aware REST requests because a generally available bulk API was not confirmed.

Can Martini integrate with Gladly?

Yes. Martini can consume Gladly REST APIs, receive selected Gladly webhook notifications through an exposed API or workflow trigger, map Gladly objects into canonical models, and route them to applications, databases, files, or analytics destinations. A native Martini Gladly connector was not confirmed, so the integration should use Gladly’s documented native mechanisms.

Do I need a connector to integrate Gladly with Martini?

No. A dedicated Gladly connector is not required. Martini can integrate with Gladly using its REST APIs, selected webhook notifications, API credentials, and supported HTTPS endpoints, with workflows handling orchestration, transformation, business rules, retries, and downstream writes.

Is there any extra Lonti cost to integrate Gladly with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Gladly. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Gladly, infrastructure providers, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Gladly integration methods should be used?

Use Gladly’s REST APIs as the primary integration method. Selected webhook-style notifications can support event-driven processing, but their coverage is partial and event-specific. A public Gladly GraphQL API and SOAP API were not confirmed, and a generally available bulk API was not confirmed.

Can Martini receive Gladly webhook events?

Yes, where Gladly provides the relevant event notification. Martini can expose an API or workflow trigger to validate, persist, transform, and route the payload. Because Gladly webhook coverage may apply only to selected events, scheduled REST reconciliation should be used where completeness is important.

How does synchronization with Gladly work?

Martini can run scheduled, paginated REST workflows using a stored timestamp, cursor, or last-seen identifier when supported by the endpoint. The workflow maps Gladly objects, writes them idempotently to the target, and advances the checkpoint only after successful processing. Stable Gladly identifiers support reconciliation and duplicate prevention.

How are Gladly errors, retries, and duplicate events handled?

Martini can distinguish authentication failures, rate limits, temporary service errors, invalid resources, validation failures, malformed notifications, and downstream failures. Transient errors can receive bounded retries, while permanent failures can be routed for review. Event or object identifiers and deterministic keys should be stored so repeated notifications do not create duplicate downstream Customers, Conversations, or Interactions.