.png)
Kustomer Integration Guide
Connect Kustomer customer-service data with enterprise applications through its versioned REST API, selected webhook notifications, and Martini workflows.
Kustomer integration options at a glance
Kustomer’s primary integration mechanism is a versioned REST API for Customers, Conversations, Messages, Users, Teams, Companies, and related resources. Kustomer also supports webhook-style notifications for selected events and resources, although coverage should be verified for each use case. API-key and OAuth 2.0 authentication use bearer tokens and account permissions. Martini can consume the REST API, receive supported notifications through an exposed API, paginate through results, apply incremental checkpoints, transform nested customer-service data, and orchestrate writes to applications or databases. Attachments may be handled through resource-specific endpoints when available; no general bulk export, direct database access, GraphQL API, or SOAP API was confirmed.
| Integration point | Supported by Kustomer? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Access and modify Customers, Conversations, Messages, Users, Teams, Companies, and related Kustomer resources. REST is the primary mechanism for synchronization and invoking Kustomer operations. | Martini can consume the versioned Kustomer REST API from workflows, configure bearer authentication, map requests and responses, handle pagination, and orchestrate downstream writes. |
| Webhooks and outbound callbacks | Limited | Receive notifications for selected Kustomer events and resources so downstream processing can begin without polling every change. | Martini can expose an authenticated REST API endpoint and route inbound Kustomer notifications into workflows. Event coverage, verification, payload completeness, and retry behavior must be confirmed for the account. |
| Authentication | Yes | Authenticate server-to-server integrations with API keys or delegated applications with OAuth 2.0 bearer tokens, subject to Kustomer permissions and scopes. | Martini can store API keys, OAuth secrets, refresh tokens, and verification values in secrets or protected environment configuration and reference them from workflows. |
| File and attachment APIs | Limited | Process attachments or attachment references associated with Kustomer Messages and Conversations when the selected resource exposes suitable download or upload behavior. | Martini can make authenticated HTTP requests for confirmed attachment endpoints and route files to another application or storage service, while treating resource-specific behavior as a design dependency. |
| Scheduled synchronization | Yes | Reconcile data or retrieve changes not covered by Kustomer webhook notifications using paginated REST requests and incremental filters where available. | Martini can trigger scheduled workflows, persist timestamps or cursors, apply overlap windows, and resume processing after rate limits or transient failures. |
| Bulk, asynchronous, and batch APIs | Not confirmed | A general-purpose Kustomer bulk or asynchronous export API was not confirmed. Large-volume processing should use paginated REST requests instead. | Martini can orchestrate bounded batches, checkpoint progress, and handle retries, but should not assume a Kustomer bulk endpoint exists. |
| GraphQL APIs | Not confirmed | No official Kustomer GraphQL API was confirmed in the reviewed documentation; REST is the recommended basis for the integration. | Martini can consume GraphQL APIs generally, but a Kustomer GraphQL integration should not be designed without separate vendor confirmation. |
| SOAP APIs | No | No official Kustomer SOAP API was confirmed, so SOAP is not a recommended mechanism for a new Kustomer integration. | Martini can consume SOAP services generally, but Kustomer integration designs should use the confirmed REST and selected webhook mechanisms. |
How Kustomer exposes data and business events
Kustomer REST APIs
Kustomer provides a versioned REST API for reading and modifying customer-service resources such as Customers, Conversations, Messages, Users, Teams, and Companies. REST requests are the primary option for synchronization and invoking Kustomer operations.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with a bearer token, calls the relevant Kustomer endpoint, follows pagination, validates and transforms the response, applies business rules, and writes the result to one or more target systems. The workflow stores checkpoints and routes transient failures for retry.
Implementation sequence
Kustomer Webhooks
Kustomer supports webhook-style notifications for selected events and resources. Coverage is not universal, and payload completeness, request verification, and retry behavior must be checked against the relevant Kustomer configuration and documentation.
Martini implementation pattern
Martini implementation pattern: expose an authenticated Martini REST API endpoint, receive the notification, validate it according to the configured security model, identify the event and resource, retrieve the current Kustomer object when the payload is only a summary, and invoke downstream processing with duplicate protection.
Implementation sequence
Scheduled REST synchronization
For resources or events without webhook coverage, recurring synchronization can use paginated Kustomer REST requests and incremental filtering where relevant timestamp or cursor fields are available.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that reads the last successful checkpoint, requests changed resources in bounded pages, processes each page idempotently, and persists progress only after successful downstream writes. An overlap window can reduce missed changes caused by timing or eventual consistency.
Implementation sequence
Kustomer attachments
Messages and Conversations may contain attachments or attachment references. A general standalone file-transfer API was not confirmed, so the exact download or upload behavior must be verified for the selected Kustomer resource.
Martini implementation pattern
Martini implementation pattern: after processing a Message or Conversation, the workflow evaluates attachment references, calls a confirmed authenticated resource endpoint when available, validates file metadata, and routes the file to the target application or storage service without assuming attachment behavior is universal.
Implementation sequence
Common Kustomer integration patterns
Pattern 1: Sync customers to a CRM
When to use this pattern
Use this pattern when Kustomer Customers must be aligned with a CRM or back-office customer model. It supports scheduled incremental retrieval and can be extended for selected bidirectional updates.
Integration direction
Example Mapping
| Kustomer Field | Canonical Field | Target Field |
|---|---|---|
| id | customer.externalId | Account.External_Kustomer_Id__c |
| name | customer.name | Account.Name |
| customer.primaryEmail | Contact.Email | |
| company | customer.companyId | Account.Id |
Martini implementation pattern
A scheduled Martini workflow reads a saved checkpoint, retrieves paginated Customers, normalizes identity and company relationships, validates required CRM fields, and performs an idempotent upsert. Matching rules prevent duplicate contacts, while rejected records and rate-limit responses are routed for retry or review.
Martini capabilities used
- workflow scheduling
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- idempotent writes
- error handling
Pattern 2: Synchronize conversations with service cases
When to use this pattern
Use this pattern when support activity in Kustomer must create or update cases, incidents, or tickets in another service platform. It is useful for preserving conversation context and routing ownership across teams.
Integration direction
Example Mapping
| Kustomer Field | Canonical Field | Target Field |
|---|---|---|
| id | conversation.externalId | incident.u_kustomer_conversation_id |
| status | conversation.status | incident.state |
| priority | conversation.priority | incident.priority |
| assignedTeam | conversation.teamId | incident.assignment_group |
Martini implementation pattern
Martini receives a supported notification or polls for changed Conversations, retrieves related assignment and message information when needed, translates Kustomer status and priority values into ServiceNow values, and upserts the case using the Kustomer conversation ID as an external key. Retries and reconciliation prevent duplicate cases when delivery or downstream writes fail.
Martini capabilities used
- webhook receiving
- REST API consumption
- data transformation
- field validation
- business rules
- idempotency
- retry and reconciliation
Pattern 3: Route selected customer-service events
When to use this pattern
Use this pattern for selected Kustomer events that need immediate operational notification, such as escalations or priority conversation changes. It should be limited to event types supported and enabled by the Kustomer account.
Integration direction
Example Mapping
| Kustomer Field | Canonical Field | Target Field |
|---|---|---|
| event.type | notification.eventType | Slack message title |
| conversation.priority | conversation.priority | Slack message priority |
| conversation.id | conversation.externalId | Slack message reference |
| team.id | routing.teamId | Slack channel |
Martini implementation pattern
A Martini API accepts the Kustomer notification, validates the request, retrieves the current Conversation when the event payload is incomplete, evaluates priority and team-routing rules, and sends a concise Slack message. Event or object identifiers are recorded so repeated delivery does not generate duplicate alerts.
Martini capabilities used
- API exposure
- webhook processing
- resource retrieval
- conditional routing
- data mapping
- duplicate prevention
- error handling
Pattern 4: Extract customer-service data to a warehouse
When to use this pattern
Use this pattern when analysts need Customers, Conversations, Messages, Users, and Teams in a relational or analytical platform. It uses paginated REST extraction because a general Kustomer bulk export API was not confirmed.
Integration direction
Example Mapping
| Kustomer Field | Canonical Field | Target Field |
|---|---|---|
| id | sourceId | kustomer_conversations.source_id |
| createdAt | createdTimestamp | kustomer_conversations.created_at |
| status | conversationStatus | kustomer_conversations.status |
| conversation.messages | messageRows | kustomer_messages |
Martini implementation pattern
A scheduled Martini workflow reads a checkpoint, retrieves bounded pages for each resource, flattens nested structures into warehouse-oriented rows, preserves source identifiers and timestamps, and performs repeatable loads. Failed pages remain eligible for retry, while late-arriving changes are handled through overlap windows or reconciliation runs.
Martini capabilities used
- scheduled workflows
- REST API consumption
- pagination
- JSON transformation
- relational mapping
- checkpoint persistence
- retry and monitoring
Applications commonly integrated with Kustomer
Kustomer can be integrated with adjacent customer-service, CRM, commerce, collaboration, and data-platform applications. These are practical enterprise architecture patterns rather than assumptions that Kustomer provides a native integration for each product.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize Kustomer Customers and Conversations with CRM accounts, contacts, opportunities, or service processes. | Kustomer → Martini → Salesforce | Martini can consume Kustomer REST resources, normalize customer and conversation fields, and upsert Salesforce objects using stable Kustomer identifiers. A second workflow can return selected Salesforce changes to Kustomer where the business process requires bidirectional synchronization. |
| ServiceNow | Create or update incidents, cases, or customer-service records from Kustomer conversations and preserve support context across platforms. | Kustomer → Martini → ServiceNow | A Martini workflow can process selected Kustomer webhook notifications or scheduled changes, map conversation status, priority, assignee, and identifiers to ServiceNow records, and apply idempotent updates with retry handling. |
| Zendesk | Support customer-service data migration or selective synchronization between Kustomer and another support platform. | Kustomer → Martini → Zendesk | Martini can extract paginated Customers, Conversations, and Messages, translate status and participant models, and write target tickets or users while preserving source identifiers and handling duplicate prevention. |
| Jira Service Management | Create engineering or operational issues from escalated Kustomer Conversations and return issue status to support workflows. | Kustomer → Martini → Jira Service Management | A Kustomer event or scheduled workflow can evaluate escalation rules, create a Jira issue with conversation context, store the Jira key against the Kustomer identifier, and process subsequent status updates without creating duplicates. |
| NetSuite | Synchronize customer and company information so support and back-office teams share consistent account data. | NetSuite → Martini → Kustomer | Martini can retrieve or receive NetSuite customer changes, map master-data fields to Kustomer Customers and Companies, and return selected service updates through controlled workflows with validation and error routing. |
| Snowflake | Load Kustomer customer-service data for service-level reporting, operational analysis, and customer-experience analytics. | Kustomer → Martini → Snowflake | A scheduled Martini workflow can page through Kustomer resources, flatten nested Conversations and Messages into analytical structures, preserve source IDs and timestamps, and write checkpointed batches to Snowflake. |
| Slack | Notify operational teams about escalations, priority conversations, and selected customer-service events. | Kustomer → Martini → Slack | Martini can receive a supported Kustomer notification, retrieve the current resource when necessary, apply priority or team-routing rules, and send a formatted Slack notification with duplicate protection. |
| Shopify | Provide support agents with customer and commerce context when handling Kustomer Conversations. | Shopify → Martini → Kustomer | Martini can retrieve Shopify customer or order context, match it to Kustomer Customers, and update permitted customer or conversation fields while keeping system ownership and reconciliation rules explicit. |
How to build a Kustomer integration in Martini
Objective
Configure Kustomer authentication and target-system credentials without embedding secrets in workflow definitions.
Instructions in Martini
- Use a Kustomer API key or OAuth 2.0 application appropriate to the integration.
- Store bearer tokens, OAuth secrets, refresh tokens, and webhook verification values in Martini secrets or protected environment configuration.
- Grant only the Kustomer permissions required by the workflow.
- Configure target-system authentication separately and keep credentials out of mappings and source-controlled files.
Objective
Select event-driven processing for supported Kustomer events and scheduled synchronization for uncovered resources or reconciliation.
Instructions in Martini
- Expose a Martini API endpoint for supported Kustomer webhook notifications.
- Use a scheduler for incremental REST synchronization and reconciliation.
- Document which resource changes are event-driven and which require polling.
- Define the checkpoint, cursor, or overlap-window strategy before processing data.
Objective
Consume the relevant Kustomer REST resource and obtain complete data when a webhook payload is only a notification summary.
Instructions in Martini
- Call the versioned Kustomer REST endpoint over HTTPS.
- Follow pagination and bound concurrency for larger data sets.
- Retrieve related Customers, Conversations, Messages, Users, Teams, Companies, or attachments only when required.
- Persist progress so transient failures can resume without reprocessing the entire run.
Objective
Coordinate validation, enrichment, routing, target writes, and response handling in a maintainable Martini workflow.
Instructions in Martini
- Separate resource retrieval from mapping and business rules where practical.
- Apply routing rules for conversation status, priority, team, or escalation.
- Use reusable workflow logic for common authentication, pagination, and error handling.
- Return an appropriate response to inbound webhook requests and process downstream work safely.
Objective
Translate Kustomer’s nested customer-service model into the target application or analytical schema.
Instructions in Martini
- Map stable Kustomer IDs to canonical external identifiers.
- Normalize timestamps, statuses, priorities, participants, tags, custom fields, and team assignments.
- Define how Conversations relate to Messages and how attachments are represented.
- Validate required fields and preserve useful source data for traceability.
Objective
Enforce ownership, filtering, matching, duplicate prevention, and data-quality decisions before downstream writes.
Instructions in Martini
- Use deterministic keys for idempotent upserts.
- Apply customer and company matching rules before creating new target objects.
- Filter events and records according to supported business scope.
- Handle missing, optional, late-arriving, or unknown fields explicitly.
Common Kustomer data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Customers | Synchronize people or organizations that interact with the company and maintain customer identity across systems. | Salesforce, NetSuite, Snowflake, Zendesk | Martini retrieves or receives Customer data, maps standard and custom fields, applies identity and validation rules, and performs idempotent upserts. |
| Conversations | Represent customer-service interactions, lifecycle, participants, channels, priority, assignment, and status. | ServiceNow, Salesforce, Zendesk, Jira Service Management, Snowflake | Martini transforms nested conversation structures, maps statuses and priorities, preserves the Kustomer identifier, and routes failures for retry or reconciliation. |
| Messages | Represent individual inbound or outbound communications associated with Conversations. | Snowflake, Zendesk, Salesforce, data stores | Martini can normalize message content, timestamps, participants, and attachment references, while applying ordering, filtering, and resource-specific attachment rules. |
| Users | Represent Kustomer agents or internal users who handle Conversations. | Salesforce, ServiceNow, Snowflake, identity-aware service platforms | Martini maps user identifiers, names, email addresses, and assignment relationships where permitted, with validation for target assignees. |
| Teams | Group Kustomer Users for assignment, routing, and operational ownership. | ServiceNow, Salesforce, Snowflake, Slack | Martini can synchronize team metadata, translate routing rules, and use team information when assigning or notifying downstream systems. |
| Companies | Represent organization-level customer records associated with Customers and Conversations. | Salesforce, NetSuite, Snowflake, Zendesk | Martini maps company identifiers and account attributes, links related Customers, and applies deterministic matching and upsert rules. |
Authentication and security considerations
Bearer-token authentication
Kustomer integrations use bearer tokens supplied through the HTTP Authorization header. Server-to-server workflows can use API keys, while delegated or installable applications can use OAuth 2.0.
Least-privilege access
Permissions and scopes should be limited to the Customers, Conversations, Messages, Users, Teams, Companies, or other resources required by the workflow.
Protected configuration
- Store API keys, OAuth client secrets, refresh tokens, and webhook verification values in Martini secrets or protected environment configuration.
- Use HTTPS for Kustomer API and webhook traffic.
- Validate inbound webhook requests according to the Kustomer security model configured for the account.
Operational considerations for Kustomer integrations
Pagination and checkpoints
Treat REST responses as paginated unless the endpoint states otherwise. Persist timestamps, cursors, or last-processed identifiers and use a small overlap window where timing or eventual consistency could cause missed changes.
Rate limits and retries
Handle Kustomer rate-limit responses explicitly, respect Retry-After when provided, limit concurrency, and apply exponential backoff. Persist progress so a retry can resume without duplicating downstream writes.
Idempotency and ordering
Webhook delivery and scheduled synchronization can repeat events. Store object or event identifiers, use deterministic target keys, and account for late-arriving Conversation or Message changes and asynchronous activity ordering.
Schema and attachment changes
Use tolerant mappings for optional fields, validate required values, test representative Customers, Conversations, and Messages, and verify attachment behavior for each resource before depending on it.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than an API call
Martini provides workflows that can receive Kustomer notifications, retrieve complete resources, apply business rules, transform nested customer-service data, and coordinate multiple target writes.
Maintainable integration logic
Mappings, validation, authentication, pagination, retry handling, and reusable workflow logic can be maintained separately from vendor-specific business rules, reducing the fragility of standalone scripts.
Reliable operations
- Use scheduled and event-driven processing together when webhook coverage is selective.
- Persist checkpoints and external identifiers for resumable, idempotent synchronization.
- Centralize error handling, monitoring, and operational troubleshooting across Kustomer integrations.
Frequently asked questions
Kustomer can be integrated primarily through its versioned REST API, which supports resources such as Customers, Conversations, Messages, Users, Teams, and Companies. Kustomer also provides webhook-style notifications for selected events and resources. API keys or OAuth 2.0 bearer-token authentication can secure the integration, while scheduled REST synchronization can cover changes without webhook coverage.
Yes. Martini can integrate with Kustomer by consuming its REST API, receiving supported webhook notifications through a Martini API or workflow, transforming Kustomer data, and orchestrating writes to applications, databases, or messaging targets.
No. A dedicated Kustomer connector is not required. Martini can use Kustomer’s confirmed native integration mechanisms, including its REST API, bearer-token authentication, selected webhook notifications, and resource-specific HTTP operations where available.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Kustomer. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Kustomer, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Use the Kustomer versioned REST API as the primary integration method. Use webhook-style notifications for selected supported events when timely processing is valuable, and use scheduled incremental REST synchronization for uncovered resources, reconciliation, or large-volume extraction. No official Kustomer GraphQL or SOAP API was confirmed.
Yes. Martini can expose an API endpoint and process inbound Kustomer webhook requests. Kustomer webhook support is event- and resource-dependent, so each implementation must verify supported event types, payload contents, request validation, subscription configuration, and retry behavior.
Martini can retrieve or receive changes for Conversations and Messages, map nested participants, channels, assignments, tags, custom fields, and timestamps, and write the result to a case platform, CRM, or database. The design should define how one Conversation maps to a target case and how individual Messages and attachments are represented.
A robust Martini workflow stores Kustomer object and event identifiers, uses deterministic external keys, handles rate-limit responses with backoff and any applicable Retry-After value, and makes downstream writes safe to repeat. Failed records or pages can be routed for retry and reconciliation without creating duplicate target objects.
Related Martini documentation
APIs
Workflows
Connect Kustomer with your enterprise systems
Use Martini to build maintainable Kustomer integrations around REST APIs, selected webhook events, secure authentication, workflow orchestration, and reliable data synchronization.