.png)
Amplitude Integration Guide
Connect Amplitude with enterprise systems through REST APIs, batched event ingestion, export files, scheduled workflows, and controlled data synchronization.
Amplitude integration options at a glance
Amplitude integrations are centered on REST APIs, including the HTTP V2 API for event ingestion and the Export API for time-range event extraction. HTTP V2 supports batched event submission using fields such as user_id, device_id, event_type, event_properties, user_properties, insert_id, and groups. Export responses can be downloaded as compressed files containing event data for processing in warehouses or downstream applications. Product-specific webhook or destination capabilities may support selected notifications, but they are not universal for every analytics event. Martini can authenticate with API keys, secret keys, and endpoint-specific credentials, orchestrate real-time or scheduled workflows, validate and transform JSON, process export files, and expose a REST API for controlled event intake.
| Integration point | Supported by Amplitude? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Amplitude REST APIs support event ingestion, user and property operations, exports, cohort-related operations, and other product-specific functions. Availability varies by endpoint, product, and plan. | Martini can consume Amplitude REST APIs from workflows, configure endpoint-specific authentication, transform JSON payloads, and expose its own REST APIs for controlled intake. |
| Bulk / async / batch APIs | Yes | The HTTP V2 API supports batched event ingestion, while the Export API supports time-range extraction with downloadable export results. | Martini can batch events, isolate failed payloads, schedule export jobs, persist watermarks, parse results, and load transformed data into downstream systems. |
| File / attachment APIs | Limited | Amplitude Export API results can be downloaded as compressed event-data files. Amplitude is not a general document or attachment repository. | Martini can download, decompress where required, parse JSON event data, validate schemas, and route the result to warehouses or databases. |
| Webhooks / outbound callbacks | Limited | Webhook-style notifications and destination capabilities may exist for selected products, integrations, or administrative events, but they are not universal for every tracked event. | Martini can receive supported webhook-style notifications, validate their source, retrieve referenced data when necessary, and route them through workflows after product and plan verification. |
| Data warehouse integrations | Limited | Amplitude supports warehouse-oriented export architectures for selected products and plans, including patterns involving Snowflake, BigQuery, Redshift, or Databricks. | Martini can orchestrate extraction and loading workflows, transform event files, maintain checkpoints, and apply downstream deduplication and schema controls. |
| Authentication | Yes | Authentication varies by API and may use an API key, secret key, Basic Authentication, or another endpoint-specific credential format. OAuth or personal access token availability is not universal. | Martini can store credentials in secrets or environment configuration and apply endpoint-specific authentication without embedding keys in mappings or logs. |
| SDKs | Yes | Amplitude provides web, mobile, and server-side SDKs for application event collection. SDKs are generally embedded in applications rather than integration workflows. | Martini generally uses Amplitude HTTP APIs instead of embedding an SDK, while it can provide the orchestration, validation, enrichment, and delivery layer around application events. |
| Database access | Limited | Amplitude does not generally provide direct SQL access to its operational analytics store. Warehouse exports and customer-managed pipelines are the normal SQL-oriented approach. | Martini can load exported and transformed Amplitude data into supported SQL databases, but it should not assume direct access to Amplitude’s internal database. |
How Amplitude exposes data and business events
Amplitude REST APIs
Amplitude provides HTTP APIs for event ingestion, user and property operations, exports, cohort-related operations, and other product-specific capabilities. The available resources and authentication method depend on the Amplitude product, endpoint, plan, and project configuration.
Martini implementation pattern
Martini implementation pattern: a workflow calls the required Amplitude REST endpoint, supplies credentials from secured configuration, validates the response, maps JSON into a canonical model, and routes the result to an application, database, warehouse, or follow-on workflow.
Implementation sequence
Amplitude HTTP V2 ingestion
Amplitude’s HTTP V2 API accepts application events, including user_id or device_id, event_type, event_properties, user_properties, time, platform, session_id, insert_id, and groups. Batched requests are supported subject to payload and rate constraints.
Martini implementation pattern
Martini implementation pattern: Martini receives events from an application or upstream service, applies identity, consent, validation, enrichment, and deterministic deduplication rules, then submits appropriately sized batches to HTTP V2 with controlled retries.
Implementation sequence
Amplitude Export API
Amplitude’s Export API retrieves event data for a specified time range and typically produces downloadable compressed files rather than a simple paginated object list. Export availability and behavior depend on the customer’s product and plan.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow requests a time window, downloads the export result, parses the contained JSON, validates and normalizes nested properties, and loads the result into a warehouse or database using a persisted watermark and overlapping windows when late events are possible.
Implementation sequence
Amplitude webhook-style notifications
Amplitude may provide webhook-style notifications or destination capabilities for selected products, integrations, or administrative events. These capabilities should not be treated as a universal webhook for every tracked event, user-property change, or analytics calculation.
Martini implementation pattern
Martini implementation pattern: Martini receives only a confirmed notification type, verifies the configured security mechanism, determines whether the payload is complete or references another resource, and invokes a follow-up API call when needed. Product, event, retry, replay, and plan behavior must be verified first.
Implementation sequence
Amplitude export files
Amplitude export results can be delivered as compressed files containing event data. This supports file-oriented warehouse and downstream processing, but does not make Amplitude a general attachment-management platform.
Martini implementation pattern
Martini implementation pattern: Martini treats the export as a controlled batch input, decompresses and parses the file, validates event contracts and privacy rules, transforms nested properties, and delivers records to the selected warehouse or SQL target.
Implementation sequence
Common Amplitude integration patterns
Pattern 1: Send application transaction events to Amplitude
When to use this pattern
Use this pattern when order, subscription, support, or product events must pass through centralized validation, enrichment, consent checks, or business rules before reaching Amplitude. It avoids coupling every source application directly to Amplitude’s event schema.
Integration direction
Example Mapping
| Amplitude Field | Canonical Field | Target Field |
|---|---|---|
| sourceEventId | event.id | insert_id |
| customerId | identity.userId | user_id |
| eventName | event.type | event_type |
| orderTotal | commerce.amount | event_properties.amount |
Martini implementation pattern
A Martini API or workflow receives the source event, validates identity and event type, enriches it with approved account or subscription data, checks consent and privacy rules, maps it to the HTTP V2 schema, and submits it in a controlled batch. The workflow reuses the same insert_id during retries, isolates invalid events, and routes failures for operational review.
Martini capabilities used
- APIs
- workflows
- data mapping
- business rules
- validation
- error handling
Pattern 2: Export Amplitude events to a data warehouse
When to use this pattern
Use this pattern when analytics teams need Amplitude event data alongside operational, customer, advertising, or commerce data in Snowflake, Google BigQuery, Databricks, or another approved target.
Integration direction
Example Mapping
| Amplitude Field | Canonical Field | Target Field |
|---|---|---|
| event_type | event.name | event_name |
| user_id | identity.userId | user_id |
| event_properties | analytics.properties | event_properties_json |
| time | event.occurredAt | occurred_at |
Martini implementation pattern
A scheduled Martini workflow requests a defined Export API window, downloads the compressed result, parses and normalizes JSON, validates schemas and privacy controls, and loads the data into the target warehouse. It persists a watermark, uses overlapping windows for late-arriving events, and applies deterministic downstream keys so repeated exports do not duplicate data.
Martini capabilities used
- scheduled workflows
- API consumption
- file processing
- JSON handling
- data mapping
- database loading
- error handling
Pattern 3: Synchronize customer attributes to Amplitude
When to use this pattern
Use this pattern when Salesforce, HubSpot, Stripe, or another authoritative customer system owns plan, account, subscription, region, or lifecycle attributes that should be available for Amplitude analysis.
Integration direction
Example Mapping
| Amplitude Field | Canonical Field | Target Field |
|---|---|---|
| Account.Id | customer.accountId | groups.account_id |
| Contact.Id | identity.userId | user_id |
| LifecycleStage | customer.lifecycleStatus | user_properties.lifecycle_status |
| Plan.Name | subscription.plan | user_properties.plan |
Martini implementation pattern
Martini retrieves source attributes, resolves the customer identity, filters fields approved for analytics, validates types and consent, and sends user or group property updates through the applicable Amplitude API. The workflow defines the source of truth, avoids overwriting Amplitude-managed behavioral values, and records rejected or unmatched identities for remediation.
Martini capabilities used
- API consumption
- workflows
- identity mapping
- data transformation
- validation
- business rules
- monitoring
Pattern 4: Synchronize Amplitude cohorts to a downstream application
When to use this pattern
Use this pattern when a supported Amplitude product and API expose cohort operations and a downstream system such as Braze or Salesforce needs refreshed audience membership.
Integration direction
Example Mapping
| Amplitude Field | Canonical Field | Target Field |
|---|---|---|
| cohort_id | audience.id | segment.external_id |
| user_id | identity.userId | external_user_id |
| cohortMembershipAdded | audience.added | segment_members.add |
| cohortMembershipRemoved | audience.removed | segment_members.remove |
Martini implementation pattern
Martini retrieves the supported cohort definition or membership, maps Amplitude identifiers to downstream identifiers, computes additions and removals, applies deletion and privacy rules, and submits the resulting audience changes. It maintains a synchronization checkpoint, handles users with no downstream match, and retries transient target failures without duplicating membership changes.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- identifier reconciliation
- error handling
Applications commonly integrated with Amplitude
Amplitude is commonly placed in an event, customer-data, and analytics architecture alongside CRM, marketing, warehouse, billing, and customer-data products. The exact capabilities and synchronization direction depend on the Amplitude product, API access, and customer plan. Martini can provide the orchestration layer when data requires validation, enrichment, identifier mapping, scheduling, or controlled delivery.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Combine product-usage behavior with Accounts, Contacts, opportunities, and lifecycle data, or deliver selected analytics audiences and engagement signals to sales teams. | Salesforce → Martini → Amplitude | Martini retrieves approved Salesforce customer attributes, maps account and contact identifiers to Amplitude user properties or groups, validates privacy rules, and submits updates through the relevant Amplitude API. A reverse workflow can retrieve supported Amplitude audience or engagement data and update Salesforce. |
| HubSpot | Combine product behavior with contact, company, lifecycle, and campaign data for qualification and journey analysis. | HubSpot → Martini → Amplitude | A Martini workflow retrieves HubSpot contact or company data, applies an identifier and consent policy, transforms attributes into Amplitude user or group properties, and sends them through the appropriate API. Reverse synchronization is limited to supported Amplitude capabilities and tenant configuration. |
| Snowflake | Centralize Amplitude event data with operational and customer data for SQL analysis, reporting, and machine-learning workloads. | Amplitude → Martini → Snowflake | A scheduled Martini workflow requests an Amplitude Export API time range, downloads and parses the compressed JSON file, validates event types and identifiers, deduplicates by deterministic keys, and loads the result into Snowflake using the customer’s approved database or loading process. |
| Google BigQuery | Query Amplitude events alongside advertising, application, and commerce datasets in a warehouse environment. | Amplitude → Martini → Google BigQuery | Martini maintains an export watermark, retrieves overlapping Amplitude time windows, parses the returned event files, normalizes nested properties, and writes validated data to BigQuery while preventing duplicates caused by late-arriving events or repeated exports. |
| Databricks | Combine behavioral events with lakehouse data for segmentation, advanced analytics, and modeling. | Amplitude → Martini → Databricks | Martini schedules Amplitude extraction, transforms event JSON into the customer’s lakehouse contract, applies schema and privacy validation, and delivers the result through the approved Databricks or customer-managed pipeline. Product and plan support should be confirmed before implementation. |
| Braze | Use Amplitude cohorts or behavioral segments for lifecycle messaging and personalization, and optionally return campaign engagement signals to the analytics model. | Amplitude → Martini → Braze | Martini retrieves supported Amplitude cohort membership, maps Amplitude user identifiers to Braze identifiers, computes additions and removals, and submits only approved audience changes. It can also route selected Braze events to Amplitude’s HTTP V2 API. |
| Stripe | Relate subscription, payment, and plan events to product usage, conversion, retention, and monetization analysis. | Stripe → Martini → Amplitude | Martini receives or retrieves Stripe events, validates their source and payment status, maps subscription and plan data into Amplitude event and user-property fields, assigns a deterministic insert_id, and submits batched events with retry and dead-letter handling. |
| Segment | Use a customer-data routing layer to collect and distribute product events to Amplitude and other analytics destinations. | Segment → Martini → Amplitude | Where a controlled intermediary is required, Martini receives Segment event payloads through an API, validates the canonical event contract, applies consent and identity rules, maps the payload to HTTP V2 fields, and forwards it to Amplitude without assuming a dedicated native connector. |
How to build a Amplitude integration in Martini
Objective
Establish the Amplitude project, endpoints, and API-specific credentials required by the integration without embedding secrets in workflow logic.
Instructions in Martini
- Confirm the Amplitude product, project, region, and endpoint requirements
- Identify whether the endpoint uses an API key, secret key, Basic Authentication, or another documented format
- Store credentials in Martini secrets or secured environment configuration
- Configure the source and target connections
Objective
Select an invocation model that matches the integration’s timing and volume requirements.
Instructions in Martini
- Use an API trigger for controlled event intake
- Use a scheduled trigger for Export API extraction or periodic attribute synchronization
- Use a webhook trigger only after confirming the Amplitude product and event delivery contract
- Use queueing or staging when high-volume delivery must be decoupled from the source transaction
Objective
Acquire source events, Amplitude API results, cohort data, or export files in a controlled workflow.
Instructions in Martini
- Receive the source payload or request the required Amplitude resource
- For exports, calculate the time window from a persisted watermark
- Download and validate the generated export file
- Capture correlation identifiers and source metadata for auditability
Objective
Coordinate validation, enrichment, routing, API calls, file handling, and downstream writes as a maintainable Martini workflow.
Instructions in Martini
- Separate ingestion, transformation, delivery, and error branches
- Apply source-of-truth and consent rules before writing analytics data
- Use reusable workflow logic for common authentication, validation, and retry behavior
- Route permanent failures to an operational review path
Objective
Convert source payloads and Amplitude responses into canonical event, identity, property, cohort, or warehouse models.
Instructions in Martini
- Map user_id, device_id, event_type, event_properties, and user_properties explicitly
- Normalize timestamps, identifiers, nested JSON, and property types
- Generate a deterministic insert_id from the source event identifier where applicable
- Preserve raw data or source metadata when downstream audit requirements demand it
Objective
Control which data is sent, accepted, updated, or discarded based on privacy, identity, quality, and ownership policies.
Instructions in Martini
- Validate required identifiers and event names
- Enforce consent, sensitive-data, retention, and regional processing rules
- Prevent unauthorized overwrites of Amplitude-managed properties
- Define how unmatched cohort or customer identifiers are handled
Common Amplitude data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Events | Represent user or system actions such as page views, purchases, searches, and feature usage. | Snowflake, Google BigQuery, Databricks, Braze, Salesforce, SQL databases | Martini validates event_type, timestamps, identifiers, properties, and source metadata, then maps the payload to HTTP V2 ingestion or export-processing models. |
| Users | Identify authenticated or anonymous users through user_id, device_id, or both. | Salesforce, HubSpot, Braze, data warehouses, customer databases | Martini applies a canonical identity strategy, preserves identifier relationships, and prevents accidental replacement of stable user or device identifiers. |
| User properties | Store attributes such as plan, region, account identifier, and lifecycle status. | Salesforce, HubSpot, Braze, Snowflake, Google BigQuery | Martini maps approved source attributes, validates property types, applies consent and privacy rules, and avoids overwriting behaviorally managed values without an explicit rule. |
| Groups | Associate users with accounts, organizations, teams, or other business-level groupings. | Salesforce, HubSpot, data warehouses, customer-success platforms | Martini maps account or organization identifiers to group data, checks authoritative-source rules, and handles missing or changed memberships explicitly. |
| Cohorts | Represent user segments created from behavioral, demographic, or imported criteria. | Braze, Salesforce, HubSpot, customer-success applications | Martini retrieves supported cohort data, translates identifiers, computes additions and removals where required, and records synchronization checkpoints. |
| Projects | Organize Amplitude data and define the project context receiving analytics events. | Configuration stores, governance workflows, operational inventories | Martini keeps project-specific credentials and endpoints in secured configuration and routes events to the intended Amplitude project. |
Authentication and security considerations
Endpoint-specific credentials
Amplitude authentication varies by API. HTTP V2 ingestion uses an API key, while selected management, export, and administrative APIs may require a secret key with Basic Authentication or another documented credential format. OAuth or personal access tokens should not be assumed for every endpoint.
Credential protection
Store Amplitude API keys and secret keys in Martini secrets or secured environment configuration. Do not place credentials in mappings, source code, URLs, or log messages.
Privacy and access control
Event payloads may contain user identifiers and user properties. Integration designs should account for consent, Amplitude project and organization permissions, deletion requests, retention policies, regional requirements, and organizational data governance rules.
Operational considerations for Amplitude integrations
Throughput and rate limits
HTTP V2 batching must respect Amplitude event-count, request-size, property, regional endpoint, and rate-limit constraints. Smaller batches can simplify retry isolation, while staging or queueing can prevent temporary failures from blocking a business transaction.
Identity and idempotency
Define how user_id, device_id, CRM identifiers, account identifiers, and anonymous-to-authenticated transitions relate. Use deterministic insert_id values where applicable and preserve them across retries.
Exports and late data
Export workflows should persist a watermark, use overlapping time windows when late-arriving events are possible, and deduplicate during warehouse loading. Track incomplete or failed export jobs separately from successful loads.
Schema and privacy testing
Validate event names, required properties, data types, timestamps, identifiers, consent rules, and sensitive-data policies before delivery. Test representative payloads, throttling behavior, export parsing, retries, and downstream duplicate handling.
Monitoring and recovery
Capture request outcomes, export windows, file checkpoints, rejected events, retry counts, and downstream load results. Separate authentication, validation, throttling, service, parsing, and database failures so operators can apply the correct remediation.
Why use Martini instead of scripts or point-to-point integrations?
Centralized integration logic
Martini provides a workflow layer for receiving events, calling Amplitude APIs, processing exports, mapping data, applying consent and identity rules, and delivering results to multiple systems.
Reliable operations
Instead of embedding one-off retry and transformation logic in individual scripts, Martini can standardize validation, deterministic identifiers, backoff, error routing, checkpoints, and monitoring across integrations.
Controlled API architecture
Martini can expose a REST API that gives applications a governed event intake surface before data is forwarded to Amplitude. This supports canonical contracts, enrichment, auditing, and controlled evolution of the Amplitude payload.
Maintainable change management
Reusable workflows and explicit mappings make it easier to support new event types, destinations, warehouse schemas, and Amplitude API requirements without creating a separate point-to-point implementation for every application.
Frequently asked questions
Amplitude can be integrated through its REST APIs, including the HTTP V2 API for event ingestion and the Export API for time-range event extraction. Integrations can also use batched requests, compressed export files, warehouse-oriented pipelines, and selected product-specific webhook or destination capabilities. Authentication varies by endpoint and may use API keys, secret keys, Basic Authentication, or other documented credentials.
Yes. Martini can consume Amplitude REST APIs, send application events to the HTTP V2 ingestion API, schedule Export API requests, process exported JSON files, and load transformed data into downstream applications or databases. Martini can also receive webhook-style notifications where the relevant Amplitude product and event type support them.
No. A dedicated Amplitude connector is not required. Martini can integrate with Amplitude using its native REST APIs, HTTP V2 ingestion endpoint, Export API files, supported webhook-style mechanisms, and endpoint-specific authentication methods.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Amplitude. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Amplitude, cloud infrastructure, data warehouses, or other third-party systems depending on subscription, usage, and deployment model.
Use the HTTP V2 API for application event ingestion and batching, and use the Export API when extracting event data for warehouses or downstream processing. Other REST APIs may support user properties, cohorts, projects, or product-specific operations. Webhook-style notifications should be used only for confirmed product and event types; no general Amplitude GraphQL or SOAP API was confirmed.
Not as a general assumption. Amplitude webhook-style notifications and destination capabilities are product-specific and may apply only to selected notifications or administrative events. For ordinary behavioral event collection, the HTTP V2 ingestion API or a supported event pipeline is generally more appropriate.
Martini can use API-triggered or scheduled workflows to retrieve Amplitude data, process compressed export files, map user_id, device_id, event_type, properties, groups, and cohort identifiers to a canonical model, and write the result to warehouses, databases, or applications. Watermarks, overlapping export windows, deterministic keys, and identifier reconciliation help manage late-arriving data and repeated runs.
Martini can classify authentication failures, validation errors, throttling, temporary service failures, export failures, parsing errors, and downstream write failures. Transient failures can use controlled retries and backoff, while permanent payload errors can be routed for correction. Stable source event identifiers should be reused as Amplitude insert_id values where applicable so retries do not create duplicate events.
Related Martini documentation
Amplitude APIs
Data processing
Build a reliable Amplitude integration with Martini
Use Martini to orchestrate Amplitude APIs, event ingestion, exports, data mapping, authentication, and operational workflows across your enterprise systems.