Ellipse Gradient for Header

Airship Integration Guide

Connect Airship’s REST APIs and selected webhook events with enterprise workflows for messaging, audience management, channel synchronization, and engagement reporting.

Airship integration options at a glance

Airship’s primary server-side integration mechanism is its JSON-based REST API, which supports channels, named users, audiences, messages, templates, preferences, reports, and related engagement operations. Airship also supports webhook-style delivery for selected events, allowing external HTTPS endpoints to receive delivery or engagement notifications. Audience-based and asynchronous messaging can support higher-volume workflows, while reporting APIs can provide data for reconciliation and analytics. Airship uses bearer authentication with API tokens. Martini can consume these APIs, receive selected webhook events, schedule synchronization workflows, map and validate payloads, apply consent rules, and expose controlled APIs for internal applications.

Integration pointSupported by Airship?Common use casesHow Martini supports it
REST APIsYesAirship REST APIs support server-side channel operations, Named Users, audiences, messages, templates, preferences, reporting, and related administration. Requests and responses are generally JSON-based.Martini can consume Airship REST APIs from workflows, map internal data into Airship payloads, validate requests, and expose controlled internal APIs that abstract Airship operations.
Webhooks / outbound callbacksLimitedAirship supports webhook-style delivery for selected events and data streams, including certain message delivery or engagement notifications. Coverage depends on the specific webhook capability.Martini can expose an authenticated webhook endpoint, start a workflow on receipt, acknowledge promptly, deduplicate events, and route normalized data to downstream systems.
Bulk / async / batch APIsLimitedAudience selectors and asynchronous messaging support higher-volume delivery patterns. Batch or asynchronous reporting behavior is endpoint-specific and may require polling or completion handling.Martini can orchestrate asynchronous requests, control concurrency, persist request identifiers, poll where required, and reconcile accepted requests with later outcomes.
AuthenticationYesAirship server-side API access uses API tokens sent as bearer tokens in the HTTP Authorization header. Permissions depend on account, organization, project, tenant, and token configuration.Martini stores tokens in secrets or protected environment configuration and applies them to API requests without embedding credentials in workflow logic.
Reporting and engagement APIsYesAirship reporting and event APIs can provide delivery and engagement information for reconciliation, analytics, and customer-service processes.Martini can retrieve reports on a schedule or process supported event notifications, normalize results, and write them to databases, warehouses, or business applications.
Database / analytics accessLimitedAirship data can be obtained through reporting or event APIs, but direct Airship database access was not confirmed.Martini can consume the confirmed Airship APIs and write approved reporting data to an enterprise database or analytics platform.
SDKsYesAirship client SDKs support application-side channel registration, notification receipt, in-app behavior, and client-side engagement capture.Martini complements rather than replaces Airship SDKs by orchestrating server-side APIs, customer data, messaging, and reporting workflows.
GraphQL APIsNot confirmedNo official Airship GraphQL API was confirmed in the reviewed documentation; REST APIs are the appropriate documented server-side interface.Martini can consume REST APIs instead. A GraphQL integration should not be assumed without separate Airship confirmation.

How Airship exposes data and business events

Airship REST APIs

Airship REST APIs are the primary server-side integration interface for managing Channels, Named Users, Audiences, Messages, Templates, Preferences, reports, and related resources. The APIs generally use JSON payloads and bearer-token authentication.

Martini implementation pattern

Martini workflows call the relevant Airship endpoint, validate and transform source data, apply consent and targeting rules, and handle the response. Reusable Martini APIs can present controlled business operations such as sending an approved message or synchronizing a Named User without exposing Airship details to every calling application.

Implementation sequence

Authenticate with an appropriately scoped Airship API token
Receive an application event or retrieve eligible source data
Resolve the relevant Named User, Channel, Audience, or preference state
Validate required fields and apply consent and business rules
Map the canonical model into an Airship JSON request
Call the Airship REST API and capture the response identifier or status

Airship webhooks

Airship supports webhook-style delivery for selected events and data streams, including certain delivery and engagement notifications. Webhook coverage, payloads, retry behavior, and security configuration depend on the specific Airship capability.

Martini implementation pattern

Martini exposes an HTTPS endpoint through an API or webhook-triggered workflow. The workflow acknowledges valid notifications promptly, verifies the configured security mechanism, deduplicates and normalizes the event, and performs downstream processing asynchronously when the work is substantial.

Implementation sequence

Receive the selected Airship webhook notification
Verify the configured authentication, signature, or shared-secret mechanism
Capture the Airship event or delivery identifier and correlation metadata
Reject or quarantine malformed or unauthorized payloads
Normalize the event into the downstream canonical model
Write the event to the target system and store the deduplication checkpoint

Airship reporting and asynchronous operations

Airship supports audience-based and asynchronous messaging patterns, while reporting and data operations may require endpoint-specific polling or completion handling. Exact response and pagination behavior varies by API.

Martini implementation pattern

Martini uses a scheduled workflow or an event-driven process to submit or retrieve data, persist request identifiers and cursors, and reconcile accepted messaging activity with reports or engagement events. Controlled concurrency and endpoint-specific retry policies prevent unnecessary load and duplicate processing.

Implementation sequence

Start the scheduled or event-driven synchronization workflow
Retrieve the saved cursor, timestamp, request identifier, or completion state
Submit the Airship operation or request the next report page
Follow endpoint-specific pagination or polling instructions
Map and persist the returned messages, reports, or engagement results
Save the new checkpoint only after successful downstream processing

Common Airship integration patterns

Pattern 1: Trigger Airship messages from customer events

When to use this pattern

Use this pattern when Salesforce, ServiceNow, Shopify, NetSuite, or another source application should trigger an Airship message after eligibility, identity, and consent checks. It separates the source event from Airship-specific payload construction and preserves the request outcome for reconciliation.

Integration direction
Salesforce
Martini
Airship
Example Mapping
Airship FieldCanonical FieldTarget Field
customerIdcustomer.idNamed User identifier
mobileChannelcustomer.channels.mobileChannel
notificationTextmessage.content.bodyMessage notification content
consentStatuscommunication.consentAudience eligibility
Martini implementation pattern

Martini receives or retrieves the source event, resolves the Airship Named User and Channel, validates consent and campaign eligibility, transforms content and localization fields, submits the Message request, and stores the Airship request identifier. Retry handling distinguishes transient API failures from validation or consent failures and prevents a retry after an opt-out.

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

Pattern 2: Synchronize profiles, channels, and preferences

When to use this pattern

Use this pattern when a master customer or subscription system owns identity, channel, tag, attribute, or preference changes and Airship must reflect them. It is suitable for initial loading and incremental scheduled synchronization.

Integration direction
Salesforce
Martini
Airship
Example Mapping
Airship FieldCanonical FieldTarget Field
externalCustomerIdcustomer.idNamed User identifier
deviceTokencustomer.channel.addressChannel address
customerTiercustomer.attributes.tierAttribute
marketingOptIncustomer.preferences.marketingPreference or eligibility rule
Martini implementation pattern

A scheduled Martini workflow reads changes using an endpoint-specific cursor or checkpoint, compares source state with Airship data where necessary, applies create, update, association, removal, and opt-out rules, and persists progress only after successful writes. Duplicate delivery and stale-channel handling use durable business keys and checkpoints.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • validation
  • business rules
  • durable checkpoints
  • retry handling

Pattern 3: Reconcile Airship engagement events in a data warehouse

When to use this pattern

Use this pattern when delivery, open, click, or conversion information from Airship must be consolidated with campaign and customer data in Snowflake or another approved analytics store. It supports both selected webhook events and scheduled report retrieval.

Integration direction
Airship
Martini
Snowflake
Example Mapping
Airship FieldCanonical FieldTarget Field
messageIdengagement.message.idairship_message_id
eventTypeengagement.event.typeevent_type
namedUserIdcustomer.idnamed_user_id
occurredAtengagement.occurred_atevent_timestamp
Martini implementation pattern

Martini receives supported Airship events or retrieves reports, validates the source identifier, normalizes event types and timestamps, deduplicates by event or message key, and writes an analytics-ready record. Invalid records are quarantined and transient warehouse or Airship failures are retried without advancing the checkpoint prematurely.

Martini capabilities used
  • webhook-triggered workflows
  • scheduled workflows
  • data mapping
  • JSON handling
  • deduplication rules
  • error handling
  • monitoring

Pattern 4: Orchestrate campaigns and templates

When to use this pattern

Use this pattern when an approved marketing or content system owns campaign metadata and Airship is responsible for audience targeting and message delivery. It separates content approval from delivery execution and supports later report reconciliation.

Integration direction
Salesforce
Martini
Airship
Example Mapping
Airship FieldCanonical FieldTarget Field
campaignCodecampaign.idCampaign or message metadata
approvedTemplatecampaign.templateTemplate
audienceSelectorcampaign.audienceAudience selector
sendAtcampaign.schedule.send_atMessage scheduling field
Martini implementation pattern

Martini retrieves approved campaign data, validates the template and audience selector, applies channel and preference rules, transforms content into Airship template or Message requests, and records the submission result. A follow-up workflow retrieves reporting data and reconciles accepted requests with delivery outcomes.

Martini capabilities used
  • API consumption
  • workflow orchestration
  • data mapping
  • validation
  • business rules
  • scheduling
  • reconciliation

Applications commonly integrated with Airship

Airship can be incorporated into enterprise customer-engagement architectures through its REST APIs and selected webhook capabilities. The following are representative application patterns rather than claims of native Airship connectors.

Application Scenario Direction Martini Pattern
Salesforce Use CRM customer, consent, lifecycle, or service events to trigger Airship messaging and associate engagement outcomes with customer records. Salesforce → Martini → Airship Martini receives a Salesforce event or scheduled extract, resolves the Airship Named User or Channel, applies consent and eligibility rules, maps the message request, and stores the Airship response identifier for reconciliation.
ServiceNow Send mobile notifications for incidents, approvals, requests, or service updates and associate selected delivery outcomes with service records. ServiceNow → Martini → Airship A Martini workflow consumes ServiceNow changes, validates notification eligibility, resolves Airship audience data, submits a message request, and optionally writes status or engagement results back to ServiceNow.
Shopify Trigger customer engagement for order updates, abandoned carts, fulfillment events, or post-purchase journeys. Shopify → Martini → Airship Martini receives or polls Shopify order events, transforms order and customer context into an Airship message payload, checks communication preferences, and submits the eligible message through the Airship REST API.
Segment Exchange customer traits, audiences, and engagement events between a customer-data pipeline and Airship. Segment → Martini → Airship Martini normalizes Segment traits or audience changes, maps them to Airship Named Users, Tags, Attributes, or Channels, and routes selected Airship events back into the customer-data flow.
Snowflake Centralize Airship message, delivery, and engagement data for analytics, segmentation, and reporting. Airship → Martini → Snowflake Martini receives selected Airship webhook events or retrieves reports on a schedule, normalizes the event model, deduplicates by Airship identifiers, and writes structured data to Snowflake through the approved data-loading interface.
Zendesk Send proactive mobile notifications about support cases and use engagement activity in customer-service workflows. Zendesk → Martini → Airship Martini consumes eligible Zendesk ticket or customer events, resolves the Airship Named User and Channel, applies preference rules, sends the message, and records the request outcome for support workflows.
NetSuite Trigger notifications for order, fulfillment, billing, or customer lifecycle events. NetSuite → Martini → Airship A scheduled or event-driven Martini workflow retrieves relevant NetSuite data, maps it to Airship audience and message structures, validates required fields, and handles retryable API failures without duplicating messages.
Datadog Monitor integration failures, webhook delivery, API latency, and message-processing outcomes. Airship → Martini → Datadog Martini records workflow and API outcomes with correlation identifiers and forwards suitable operational metrics or logs to Datadog using the configured observability path.

How to build a Airship integration in Martini

Objective

Establish Airship access using a token with the permissions required by the selected APIs and keep environment-specific credentials outside workflow logic.

Instructions in Martini

  • Create or obtain the required Airship API token and permissions
  • Store the token in Martini secrets or protected environment configuration
  • Use separate Airship credentials or projects for development, testing, and production
  • Configure the Airship account, organization, project, or tenant context required by the endpoint

Objective

Select an event-driven, webhook-driven, API-led, or scheduled trigger based on the source application and Airship capability being integrated.

Instructions in Martini

  • Use a source application event when immediate messaging is required
  • Expose a Martini webhook endpoint for selected Airship event notifications
  • Use a scheduler for profile synchronization and report retrieval
  • Persist a cursor, timestamp, request identifier, or other durable checkpoint

Objective

Obtain the current source or Airship data required to make a safe decision rather than relying only on a notification payload.

Instructions in Martini

  • Retrieve the relevant Named User, Channel, Audience, preference, report, or Message data
  • Follow endpoint-specific pagination, cursor, or polling behavior
  • Capture Airship request, message, event, or delivery identifiers
  • Avoid advancing a synchronization checkpoint before downstream processing succeeds

Objective

Implement the end-to-end Martini workflow that coordinates validation, identity resolution, Airship API calls, downstream writes, and recovery paths.

Instructions in Martini

  • Separate accepted message requests from later delivery outcomes
  • Use controlled concurrency for higher-volume audience or reporting operations
  • Route validation failures, unauthorized events, and transient API failures separately
  • Use reusable services or workflow components for common Airship operations

Objective

Convert source-system customer, campaign, audience, and event models into Airship JSON structures and normalize Airship responses for downstream systems.

Instructions in Martini

  • Map customer identifiers to Named Users and Channels
  • Transform tags, attributes, preferences, audience selectors, and message content
  • Validate required fields, channel-specific content, and localization values
  • Normalize webhook and report events into the enterprise canonical model

Objective

Enforce consent, preference, targeting, identity, and message eligibility rules before sending or synchronizing data.

Instructions in Martini

  • Check opt-in and opt-out state before message submission
  • Define the source of truth for communication preferences
  • Handle stale channels, channel replacement, and identity conflicts explicitly
  • Prevent retries from sending a message after a user has opted out

Common Airship data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ChannelsRepresent mobile or other supported delivery addresses and support registration, querying, updating, and removal.CRM platforms, customer-data platforms, databases, and mobile applicationsMartini matches channel identifiers, applies lifecycle and consent rules, calls Airship channel APIs, and persists synchronization checkpoints or outcomes.
Named UsersProvide an application-level identity that can associate one user with multiple devices or delivery channels.Salesforce, ServiceNow, customer-data platforms, and identity or profile storesMartini resolves identity keys, creates or updates Named Users, associates Channels, and applies business rules for merges, deactivation, and stale identities.
MessagesRepresent push, web, in-app, or other engagement messages with audience selectors, content, localization, scheduling, and delivery options.Salesforce, ServiceNow, Shopify, campaign platforms, and monitoring storesMartini validates eligibility and consent, maps source content into Airship message requests, submits them, and stores request identifiers separately from delivery outcomes.
AudiencesDefine targeting using Channels, Named Users, Tags, Attributes, segments, or other selectors.Customer-data platforms, campaign systems, CRM platforms, and analytics storesMartini translates source audience rules into Airship selectors, applies validation and segmentation rules, and coordinates audience-based message workflows.
Tags and AttributesStore categorical and named-user or channel metadata for segmentation, targeting, and personalization.CRM platforms, customer-data platforms, profile stores, and data warehousesMartini compares source and Airship values, applies incremental updates, handles removals or replacements, and records synchronization results.
Message ReportsProvide delivery and engagement information for reconciliation, reporting, and campaign analysis.Snowflake, databases, Salesforce, Zendesk, Datadog, and analytics platformsMartini retrieves or receives available reporting data, normalizes event fields, deduplicates results, and writes them to approved downstream systems.

Authentication and security considerations

Bearer-token authentication

Airship server-side APIs use API tokens sent as bearer tokens in the HTTP Authorization header. Required permissions depend on the operation, account, organization, project, or tenant context.

Secret management

Store Airship tokens in Martini secrets or protected environment configuration rather than embedding them in workflows. Use separate credentials for development, testing, and production and rotate them without changing integration logic.

Webhook protection

For selected Airship webhook capabilities, verify the configured authentication, signature, or shared-secret mechanism before accepting events. Minimize sensitive identifiers and message content in logs.

Operational considerations for Airship integrations

Rate limits and retries

Airship limits may vary by endpoint, account, or plan. Use controlled concurrency, exponential backoff, and operation-specific retry rules. Do not automatically retry an operation unless its duplicate-send behavior is understood.

Pagination and checkpoints

Pagination models may differ across Airship endpoints. Persist the applicable cursor, page token, continuation link, timestamp, request identifier, or completion state only after successful processing.

Idempotency and ordering

Webhook delivery and scheduled polling can produce duplicates or out-of-order events. Use Airship event, message, delivery, or composite business identifiers for deduplication and reconciliation.

Consent and schema management

Apply preference and opt-out rules immediately before message submission. Validate required fields, keep API version assumptions explicit, and monitor changes to message, audience, reporting, and webhook schemas.

Data protection

Airship data can contain device identifiers, Named User identifiers, Attributes, and message content. Minimize retained data, mask tokens and personal information in logs, and review access and retention requirements for downstream stores.

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

Orchestration beyond a single API call

Airship integrations often require identity resolution, consent checks, audience selection, message submission, reporting, and downstream reconciliation. Martini coordinates these steps in workflows rather than leaving the logic in isolated scripts.

Reusable integration logic

Martini can expose controlled APIs for operations such as sending an approved Airship message or synchronizing a Named User. This keeps Airship-specific payloads and authentication details behind reusable integration assets.

Reliable data movement

Martini provides mapping, transformation, validation, scheduling, webhook-triggered workflows, error handling, and operational logging for event-driven and batch scenarios. These capabilities help manage retries, checkpoints, duplicate events, and schema changes.

Flexible enterprise architecture

Martini can connect Airship with applications, databases, files, and messaging systems using standards-based APIs and workflows, while allowing custom logic when the integration requires specialized business rules.

Frequently asked questions

How can Airship be integrated with enterprise systems?

Airship can be integrated through its server-side JSON REST APIs for Channels, Named Users, Audiences, Messages, Templates, Preferences, and reporting. Selected Airship events can also be delivered through webhook-style notifications to an HTTPS endpoint, while scheduled workflows can retrieve reports or synchronize customer data.

Can Martini integrate with Airship?

Yes. Martini can consume Airship REST APIs, receive supported Airship webhook events, schedule synchronization and reporting workflows, map enterprise data into Airship payloads, and expose controlled internal APIs for Airship operations.

Do I need a connector to integrate Airship with Martini?

No. A dedicated Airship connector is not required. Martini can integrate using Airship’s confirmed native mechanisms, including REST APIs, bearer-token authentication, selected webhook events, reporting APIs, and scheduled workflows.

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

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

Which Airship APIs and integration methods should an enterprise use?

Airship REST APIs are the recommended primary method for server-side integrations. Selected webhook-style events can support event-driven processing, while reporting and asynchronous operations may use scheduled retrieval, polling, or reconciliation depending on the endpoint. No official Airship GraphQL or SOAP API was confirmed.

Can Airship events trigger a Martini workflow?

Yes, for Airship capabilities that provide webhook-style event delivery. Martini can expose an authenticated endpoint and start a workflow for supported events, but webhook coverage is event-specific rather than universal across Airship objects and operations.

How does synchronization between Airship and other systems work?

Martini can synchronize Named Users, Channels, Tags, Attributes, preferences, Messages, and reporting data through event-driven or scheduled workflows. The implementation should use endpoint-specific pagination, durable checkpoints, identity matching, consent rules, and deduplication for repeated events or polling results.

How does Martini handle Airship mapping, errors, retries, and duplicate events?

Martini maps Airship JSON to canonical and target models, validates required fields, applies business rules, and routes failures through workflow error handling. Retry policies can use controlled concurrency and backoff for safe transient failures, while durable event or business keys help deduplicate webhook deliveries and scheduled processing. Martini can also expose an API façade that hides Airship-specific payloads from internal consumers.