.png)
Attentive Integration Guide
Connect Attentive’s subscriber, subscription, campaign, and messaging APIs with enterprise systems through authenticated workflows, selected webhook events, and scheduled synchronization.
Attentive integration options at a glance
Attentive provides HTTP REST APIs for working with Subscribers, Subscriptions, Brands, Campaigns, Messages, and related resources. Selected integration scenarios also support webhook-style event notifications, although coverage is event-specific and should be confirmed for each account and API product. Authentication may use account-issued API credentials or OAuth 2.0 for approved applications. Martini can consume Attentive APIs, receive supported webhook events through an exposed API, apply consent and business rules, and map data into CRM, commerce, warehouse, or customer-data systems. Scheduled workflows provide reconciliation where event coverage is incomplete, with pagination, throttling, retries, and synchronization checkpoints.
| Integration point | Supported by Attentive? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Access Subscribers, Subscriptions, Brands, Campaigns, Messages, and related Attentive resources; submit supported messaging or subscriber operations where enabled. | Martini consumes Attentive REST endpoints from workflows, applies mappings and business rules, and handles pagination, throttling, retries, and checkpoints. |
| Webhooks / outbound callbacks | Limited | Receive selected event notifications for supported integration scenarios, such as subscription or messaging-related events where available. | Martini can expose an API or webhook workflow, validate requests, deduplicate events, and route them to downstream systems. Event coverage and verification requirements must be confirmed per event type. |
| Authentication | Yes | Authenticate private server-to-server integrations with account-issued API credentials or approved applications with OAuth 2.0. | Martini stores credentials in secrets or environment configuration and uses the authentication model required by the selected Attentive API product. |
| Pagination and incremental retrieval | Yes | Retrieve lists of subscribers, campaigns, messages, or other resources using the endpoint-specific pagination and filtering model. | Martini persists cursor or page state after successful processing and can run scheduled incremental or reconciliation workflows. |
| Outbound messaging APIs | Limited | Submit or coordinate messaging activity where the account, API product, permissions, and approved use case support the operation. | Martini can call the relevant Attentive REST operation, validate consent and business rules, and handle authorization, validation, rate-limit, and transient failures. |
| Bulk / async / batch APIs | Not confirmed | A general-purpose bulk or asynchronous API covering the principal Attentive objects was not confirmed. | Martini can orchestrate controlled batches through documented REST endpoints, but should not assume a dedicated Attentive bulk interface. |
| File / attachment APIs | No | No official general-purpose file import, export, or attachment API was confirmed for the core Attentive integration API. | Martini should use documented APIs or approved external export mechanisms rather than assuming file-based Attentive integration. |
| Database / analytics access | No | Attentive does not expose direct customer database access for application integrations. | Martini can retrieve permitted data through Attentive APIs and write transformed results to supported databases or analytics platforms. |
How Attentive exposes data and business events
Attentive REST APIs
Attentive provides HTTP APIs for subscriber, subscription, brand, campaign, message, and related resources. Endpoint availability, resource naming, pagination, filters, and write permissions vary by API product and account configuration.
Martini implementation pattern
Martini workflows authenticate using the configured Attentive credential model, retrieve or submit resources, transform payloads, apply consent and business rules, and write results to downstream applications or databases. Scheduled workflows can provide incremental synchronization and reconciliation when event coverage is incomplete.
Implementation sequence
Attentive Webhook Events
Attentive supports webhook-style notifications for selected integration scenarios. Coverage is event-specific and should be confirmed for the resource, event type, account, and API product; not every Subscriber, Subscription, Campaign, or Message change should be assumed to generate an event.
Martini implementation pattern
Martini exposes a controlled API endpoint or webhook workflow, validates the request and any available verification mechanism, durably accepts the event, and maps it to downstream consent, customer, or engagement processes. A scheduled REST reconciliation workflow can recover from incomplete coverage or delivery gaps.
Implementation sequence
Attentive Authentication
Attentive integrations may use account-issued API credentials for private server integrations or OAuth 2.0 for approved applications. Scope and credential requirements depend on the selected API product and application configuration.
Martini implementation pattern
Martini keeps Attentive secrets outside workflow definitions and applies the configured authentication scheme when calling APIs. Access is limited by account, brand, application, and permissions, while workflows avoid logging credentials or unnecessary personal data.
Implementation sequence
Attentive Scheduled Synchronization
Scheduled retrieval is important when Attentive webhook coverage is limited or when historical campaign and message activity must be reconciled. The endpoint-specific pagination and incremental filtering model must be confirmed before implementation.
Martini implementation pattern
Martini scheduler-triggered workflows retrieve bounded resource windows, process pages under controlled concurrency, persist state after successful writes, and retry transient failures. Reconciliation logic compares Attentive identifiers and timestamps with downstream data to detect missing or late-arriving changes.
Implementation sequence
Common Attentive integration patterns
Pattern 1: Synchronize CRM subscribers to Attentive
When to use this pattern
Use this pattern when Salesforce or another CRM is the source for customer identity and marketing consent. It supports new and updated customer flows while preventing stale or invalid consent data from being sent to Attentive.
Integration direction
Example Mapping
| Attentive Field | Canonical Field | Target Field |
|---|---|---|
| phoneNumber | normalizedPhoneNumber | Subscriber phone number |
| marketingConsent | messagingConsentStatus | Subscription status |
| salesforceId | sourceCustomerId | Subscriber custom attribute |
Martini implementation pattern
Martini receives or retrieves CRM changes, validates opt-in and opt-out rules, normalizes phone numbers and country codes, maps the customer to Attentive Subscribers and Subscriptions, and records the returned Attentive identifier. Duplicate contacts, rejected consent, authorization failures, and transient API errors are routed through explicit exception and retry paths.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secrets management
- error handling
Pattern 2: Propagate Attentive subscription events to customer systems
When to use this pattern
Use this pattern to keep CRM, customer-data, or compliance systems aligned with selected Attentive subscription and unsubscribe events. Because webhook coverage is partial, pair the event flow with scheduled reconciliation.
Integration direction
Example Mapping
| Attentive Field | Canonical Field | Target Field |
|---|---|---|
| subscriberId | customerMessagingId | Attentive subscriber reference |
| subscriptionStatus | marketingConsentStatus | Contact consent status |
| eventTimestamp | consentChangedAt | Consent audit timestamp |
Martini implementation pattern
Martini receives supported Attentive webhook-style notifications, validates and durably accepts each event, suppresses duplicates, and updates downstream consent records. Business rules prevent stale data from re-subscribing an opted-out contact; a scheduled REST workflow compares current Subscription state to recover missed events.
Martini capabilities used
- API exposure
- webhook consumption
- workflows
- data mapping
- business rules
- scheduled synchronization
- monitoring
Pattern 3: Send commerce events to Attentive messaging processes
When to use this pattern
Use this pattern when Shopify, NetSuite, or another commerce application provides order, fulfillment, product, or customer events that can support an approved Attentive messaging use case.
Integration direction
Example Mapping
| Attentive Field | Canonical Field | Target Field |
|---|---|---|
| order.id | orderId | Attentive order-related attribute |
| customer.phone | normalizedPhoneNumber | Subscriber phone number |
| fulfillment.status | fulfillmentStatus | Attentive custom attribute |
Martini implementation pattern
Martini receives commerce events, validates the customer and consent context, enriches the payload with permitted order or fulfillment data, and calls the relevant Attentive API only when the account and API product support the operation. Rate limits, duplicate order events, validation errors, and messaging restrictions are handled explicitly.
Martini capabilities used
- event-driven workflows
- API consumption
- data transformation
- business rules
- throttling
- error handling
Pattern 4: Reconcile Attentive campaign and message activity
When to use this pattern
Use this pattern when an organization needs normalized Attentive Campaigns and Messages data in Snowflake, a reporting database, or an analytics platform.
Integration direction
Example Mapping
| Attentive Field | Canonical Field | Target Field |
|---|---|---|
| campaignId | marketingCampaignId | CAMPAIGN_ID |
| messageId | engagementMessageId | MESSAGE_ID |
| eventTimestamp | activityAt | ACTIVITY_AT |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated campaign and message activity using supported filters, transforms the payload into a reporting schema, and writes records with stable identifiers. It persists checkpoints after successful pages, retries transient failures with bounded backoff, and detects late-arriving or updated records without duplicate inserts.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- SQL/database integration
- checkpointing
- retry handling
Applications commonly integrated with Attentive
Attentive can be integrated with commerce, CRM, marketing, customer-data, support, and analytics applications. Exact object and event coverage depends on the Attentive account, API product, permissions, and the capabilities of the adjacent application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Synchronize customers, orders, products, and commerce events to support consent-aware SMS marketing and customer engagement. | Shopify → Martini → Attentive | Martini receives Shopify events or retrieves commerce data, validates consent, normalizes customer details, maps the result to Attentive Subscribers and Subscriptions, and records returned identifiers with retry and duplicate handling. |
| Salesforce | Align CRM contacts, consent, customer attributes, and selected engagement activity with Attentive subscriber data. | Salesforce → Martini → Attentive | A Martini workflow consumes Salesforce changes, applies consent and phone-number validation, maps contacts to Attentive Subscribers and Subscriptions, and periodically reconciles status in both systems. |
| Klaviyo | Coordinate subscriber profiles, consent, segments, and campaign activity across marketing platforms where the account permits the use case. | Klaviyo → Martini → Attentive | Martini maps profile and consent models between the platforms, applies source-of-truth rules, routes rejected or conflicting updates for review, and uses identifiers to prevent duplicate synchronization. |
| Snowflake | Centralize Attentive subscriber, campaign, message, and engagement data for analytics, governance, and reporting. | Attentive → Martini → Snowflake | Scheduled Martini workflows retrieve paginated Attentive resources, apply time-window and checkpoint logic, normalize JSON into reporting tables, and write late-arriving updates without duplicating identifiers. |
| Segment | Propagate customer traits and behavioral events for profile and audience synchronization where the relevant Attentive destination or source capability is available. | Segment → Martini → Attentive | Martini receives approved Segment events, filters and enriches traits, applies consent rules, and calls the relevant Attentive REST operation while retaining correlation and replay information. |
| NetSuite | Combine order, customer, and fulfillment information with Attentive subscriber and engagement data for enterprise commerce processes. | NetSuite → Martini → Attentive | Martini retrieves or receives NetSuite business events, transforms customer and order attributes, applies messaging eligibility rules, and sends only supported data to Attentive APIs. |
| Zendesk | Use support customer information and consent state in coordinated customer-engagement processes. | Zendesk → Martini → Attentive | A Martini workflow maps approved Zendesk customer changes to Attentive subscriber data, protects opt-out state, and optionally routes selected Attentive activity back for support context. |
How to build a Attentive integration in Martini
Objective
Establish the Attentive API connection using the credential model required by the selected API product and limit access to the necessary account, brand, application, and resource permissions.
Instructions in Martini
- Confirm whether the integration uses API credentials or OAuth 2.0
- Store credentials in Martini secrets or environment configuration
- Configure the Attentive REST API request authentication
- Test authorization and permission boundaries
Objective
Select an event-driven, API-led, or scheduled entry point based on the required business latency and Attentive’s event coverage for the relevant resource.
Instructions in Martini
- Use a Martini API or webhook workflow for supported Attentive notifications
- Use a scheduler trigger for polling, backfill, and reconciliation
- Define the source system and synchronization direction
- Document the event and resource coverage assumptions
Objective
Receive webhook payloads or retrieve Attentive resources through paginated REST calls while preserving enough state to resume safely.
Instructions in Martini
- Validate incoming webhook requests before processing
- Implement the endpoint-specific pagination model
- Persist cursors, page state, or time checkpoints after successful processing
- Use controlled concurrency and respect rate limits
Objective
Coordinate validation, enrichment, Attentive API calls, downstream writes, and exception paths in a maintainable Martini workflow.
Instructions in Martini
- Separate trigger, validation, transformation, API, and persistence stages
- Apply source-of-truth rules for consent and subscription state
- Use reusable workflow logic for common Attentive operations
- Route invalid business data separately from transient technical failures
Objective
Convert Attentive Subscribers, Subscriptions, Campaigns, Messages, and custom attributes into the canonical model required by downstream systems.
Instructions in Martini
- Normalize phone numbers and country codes
- Map stable vendor and source identifiers
- Handle optional attributes without assuming they are always present
- Preserve relevant timestamps and correlation information
Objective
Enforce consent, messaging eligibility, brand scope, duplicate prevention, and data-minimization rules before writing or sending data.
Instructions in Martini
- Prevent stale data from overwriting an unsubscribe
- Validate approved messaging use cases and required permissions
- Use deterministic keys for duplicate detection
- Minimize personal data copied to downstream systems
Common Attentive data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Subscribers | Represent people associated with an Attentive account or brand, including contact details and subscription-related attributes. | Salesforce, Shopify, Klaviyo, Segment, Snowflake | Martini validates consent and identifiers, normalizes phone numbers, maps subscriber fields, stores source-to-Attentive identifiers, and handles duplicates and API errors. |
| Subscriptions | Represent a subscriber’s subscription status for a messaging channel, list, or subscription type. | Salesforce, Klaviyo, Segment, customer data stores | Martini treats subscription and opt-out changes as compliance-sensitive, applies source-of-truth rules, and reconciles webhook-driven updates with scheduled API retrieval. |
| Brands | Represent Attentive customer brands or business accounts that own messaging programs and subscriber data. | Configuration stores, CRM, data warehouse | Martini uses brand context to scope credentials, mappings, business rules, and synchronization keys where the selected API exposes it. |
| Campaigns | Represent scheduled or configured marketing messaging campaigns. | Snowflake, reporting databases, analytics platforms | Martini retrieves campaign data with pagination and time filters where supported, transforms it into reporting models, and records synchronization checkpoints. |
| Messages | Represent individual outbound messages or message activity associated with campaigns, journeys, or other messaging programs. | Snowflake, reporting databases, customer profiles | Martini normalizes message activity, handles late-arriving updates, preserves Attentive identifiers and timestamps, and retries transient retrieval or write failures. |
| Custom attributes | Store additional subscriber or profile data used for segmentation, personalization, and downstream synchronization. | Salesforce, Shopify, Segment, Snowflake | Martini maps optional attributes cautiously, preserves relevant unknown fields where practical, and applies field-level privacy and business rules. |
Authentication and security considerations
Credential models
Attentive integrations may use account-issued API credentials for private server-to-server access or OAuth 2.0 for approved applications. The required scopes, headers, and permissions depend on the API product and application configuration.
Secret handling
Store Attentive credentials in Martini secrets or environment configuration rather than workflow definitions. Limit access by account, brand, application, and resource permissions.
Webhook protection
For supported webhook events, confirm whether Attentive provides signatures, verification headers, timestamps, or another request-authentication mechanism. Validate the available controls and make event processing idempotent.
- Do not log API keys, OAuth secrets, or unnecessary subscriber data.
- Protect consent and subscription information as compliance-sensitive data.
- Rotate credentials without changing business mappings or workflow logic.
Operational considerations for Attentive integrations
Throughput and pagination
Confirm endpoint-specific rate limits, pagination, filters, and cursor behavior. Use controlled concurrency, honor 429 responses and Retry-After instructions where provided, and persist page state only after successful processing.
Idempotency and reconciliation
Use stable Attentive identifiers, normalized subscriber keys, source-system identifiers, and event timestamps to prevent duplicates. Because webhook coverage is partial, schedule REST reconciliation for important Subscriber, Subscription, Campaign, and Message data.
Consent and schema changes
Do not overwrite an unsubscribe with stale data. Preserve consent audit information, handle optional fields defensively, and version mappings as Attentive resources and event payloads evolve.
Testing and monitoring
Test authentication, permissions, pagination, rate limits, duplicate delivery, malformed payloads, and late-arriving updates. Monitor workflow outcomes and retain correlation information without exposing secrets or unnecessary personal data.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond a script
Martini coordinates Attentive API calls, webhook intake, validation, consent rules, transformations, downstream writes, retries, and reconciliation in a visible workflow rather than scattering logic across scripts.
Reusable integration assets
Teams can expose controlled APIs, reuse mappings and workflow logic, and apply environment-specific secrets without duplicating vendor-specific implementation across applications or brands.
Operational control
Martini provides structured handling for pagination, throttling, exceptions, checkpoints, and scheduled recovery. This is useful when Attentive event coverage is selected rather than universal and when multiple enterprise systems must remain aligned.
Frequently asked questions
Attentive can be integrated through its REST APIs, selected webhook-style event notifications, API-key-based server integrations, and OAuth 2.0 applications where supported. Enterprise workflows commonly synchronize Subscribers and Subscriptions, process Campaigns and Messages, send approved commerce-related data, and reconcile API data on a schedule.
Yes. Martini can integrate with Attentive by consuming its REST APIs, receiving supported webhook-style notifications through an exposed API, applying consent and business rules, and synchronizing data with systems such as Salesforce, Shopify, Snowflake, or SQL databases.
No. A dedicated Attentive connector is not required. Martini can use Attentive’s confirmed native integration mechanisms, including REST APIs, selected webhook events, API credentials, and OAuth 2.0 where applicable.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Attentive. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Attentive, cloud infrastructure, databases, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs are the primary integration method for Subscribers, Subscriptions, Brands, Campaigns, Messages, and related resources. Selected webhook-style events can support lower-latency processing, while scheduled paginated REST synchronization is recommended for reconciliation and event coverage gaps. No official public GraphQL or current SOAP API was confirmed.
No. Attentive webhook-style notifications are partial and event-specific. The available resources, event types, delivery behavior, verification mechanism, and retry semantics should be confirmed for the account and API product. Martini can combine supported events with scheduled reconciliation.
Martini maps Attentive objects to a canonical model, normalizes contact details, preserves vendor identifiers, and applies business rules before downstream writes. Subscription and unsubscribe state is treated as compliance-sensitive so stale source data does not accidentally re-subscribe a contact.
Martini can distinguish authentication, permission, validation, rate-limit, and transient server failures. Workflows can use throttling, bounded exponential backoff, durable event acceptance, stable identifiers, idempotent writes, exception routing, and checkpointed reconciliation to limit duplicate processing and recover from failures.
Related Martini documentation
Workflows
Security
Connect Attentive with your enterprise systems
Use Martini to build governed Attentive integrations for subscriber synchronization, consent propagation, messaging workflows, campaign reconciliation, and enterprise reporting.