.png)
Pendo Integration Guide
Connect Pendo product analytics, guidance, feedback, and usage data with enterprise applications through REST APIs, selected webhook callbacks, exports, and scheduled Martini workflows.
Pendo integration options at a glance
Pendo provides REST APIs for retrieving Visitors, Accounts, Pages, Features, Guides, Product Areas, usage data, analytics, and related product information. Pendo also offers export and synchronization capabilities for selected analytics and usage datasets, subject to subscription and feature availability. Webhook-style notifications are available for selected documented events, but they should not be treated as a universal event stream. Public API access uses a Pendo integration key supplied with requests. Martini can consume these APIs, receive supported callbacks, schedule incremental extraction, paginate through responses, transform data, and write results to databases, files, data warehouses, or downstream applications.
| Integration point | Supported by Pendo? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve Visitors, Accounts, Pages, Features, Guides, Product Areas, usage data, analytics, and related product information. REST APIs are the primary server-side integration mechanism for new integrations. | Martini can consume Pendo REST endpoints in workflows, handle authentication, pagination, filtering, transformation, downstream writes, and controlled API exposure. |
| Webhooks / outbound callbacks | Limited | Receive webhook-style notifications for selected documented Pendo events or integration scenarios. Coverage does not necessarily include every Pendo object or activity. | Martini can receive supported callbacks through webhook-triggered workflows, validate the request, apply business rules, retrieve additional data, and forward or persist the result. |
| Bulk / async / batch APIs | Limited | Pendo provides analytics export and synchronization patterns for selected datasets, but a universal bulk CRUD API was not confirmed. | Martini can orchestrate bounded batch extraction, process pages or time windows, maintain watermarks, and load normalized results into target systems. |
| Data export and synchronization | Limited | Export or synchronization features can provide analytics and usage data where the subscription and selected Pendo feature support them. | Martini can consume documented exports or combine them with REST extraction, validate schemas, transform datasets, and load files, databases, or downstream applications. |
| Authentication | Yes | Pendo public REST API requests use an integration key or API key, commonly supplied through the X-Pendo-Integration-Key header. OAuth 2.0 was not confirmed as the primary public API method. | Martini can store the integration key in environment configuration or secrets management and apply it to outbound requests without placing it in workflow source code. |
| SDKs and event collection | Yes | Pendo SDKs identify Visitors and Accounts, capture product usage and Track Events, deliver Guides, and collect feedback in web or mobile applications. | Martini generally integrates with the server-side API or supported webhook surface for back-office orchestration; it does not treat the SDK as a substitute for server-to-server integration. |
| Database / analytics access | Limited | Analytics data is available through Pendo APIs and documented export or synchronization features. Direct access to Pendo operational databases was not confirmed. | Martini can write retrieved or exported analytics data to supported SQL databases or warehouses while preserving source identifiers and extraction metadata. |
| GraphQL APIs | Not confirmed | No official Pendo GraphQL API was confirmed for new integrations; REST should be used for server-side API access. | Martini can consume the confirmed Pendo REST surface instead of relying on an unconfirmed GraphQL interface. |
How Pendo exposes data and business events
Pendo REST APIs
Pendo REST APIs provide the primary server-side integration surface for retrieving metadata, Visitors, Accounts, Pages, Features, Guides, Product Areas, usage information, analytics, and related product data. Endpoint access, versions, filters, and account restrictions should be confirmed against the current Pendo documentation.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with a Pendo integration key, calls the required REST endpoint, follows the endpoint's pagination model, validates and transforms the response, and writes or returns the result. Reusable workflow logic can isolate Pendo-specific request, pagination, retry, and response-handling behavior.
Implementation sequence
Pendo Webhook Callbacks
Pendo supports webhook-style notifications for selected documented events and integration scenarios. This capability is event-specific and should not be assumed to provide notifications for every Pendo object, activity type, or API operation.
Martini implementation pattern
Martini implementation pattern: a webhook-triggered workflow receives the callback, validates the available authentication or verification data, checks the event type and identifiers, and optionally calls Pendo REST APIs to retrieve the complete business payload before routing it to downstream systems.
Implementation sequence
Pendo Export and Synchronization
Pendo offers export and synchronization capabilities for selected analytics and usage datasets, with availability, destinations, and coverage dependent on subscription and feature configuration. These capabilities can complement request-based API extraction for larger or analytical workloads.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow consumes the documented export or synchronization output, validates the schema and time period, stages the data, maps Pendo identifiers to the canonical model, and loads it into a warehouse, database, file destination, or downstream application.
Implementation sequence
Pendo API Authentication
Pendo public REST API access uses an integration key or API key, commonly supplied in the X-Pendo-Integration-Key request header. OAuth 2.0 was not confirmed as the primary public API authentication method.
Martini implementation pattern
Martini implementation pattern: the integration key is stored outside workflow source code in secure environment configuration, then applied to outbound Pendo requests through the workflow's API configuration. Access and endpoint permissions remain subject to the Pendo subscription and key permissions.
Implementation sequence
Common Pendo integration patterns
Pattern 1: Synchronize Pendo accounts and visitors to Salesforce
When to use this pattern
Use this pattern when customer-success teams need product adoption and engagement context alongside CRM account and user information. A scheduled workflow can retrieve Pendo Accounts, Visitors, usage indicators, and guide activity, then update Salesforce using stable identifiers and maintained cross-references.
Integration direction
Example Mapping
| Pendo Field | Canonical Field | Target Field |
|---|---|---|
| Account ID | customer.account.externalId | Salesforce Account external identifier |
| Visitor ID | customer.user.externalId | Salesforce Contact external identifier |
| Product usage indicator | customer.productAdoption.score | Salesforce adoption field |
| Guide activity | customer.engagement.guideActivity | Salesforce engagement field |
Martini implementation pattern
A scheduler starts the workflow, which calls Pendo REST endpoints with the integration key, follows pagination, filters by an extraction window, and maps records to Salesforce schemas. Identity rules determine whether an Account or Visitor is updated, while idempotent upserts, rejected-record logging, and retry handling prevent duplicates and support replay.
Martini capabilities used
- Scheduling workflows
- API consumption
- Pagination and incremental extraction
- Data mapping
- Identity matching
- Business rules
- Error handling and retries
Pattern 2: Load Pendo usage analytics into Snowflake
When to use this pattern
Use this pattern when product usage, Track Events, account activity, or analytics must be combined with subscription, support, CRM, or renewal data. It is suitable for scheduled API extraction or documented Pendo exports rather than repeated full-history requests.
Integration direction
Example Mapping
| Pendo Field | Canonical Field | Target Field |
|---|---|---|
| Track Event name | product.usage.eventName | Snowflake event_name |
| Visitor ID | product.usage.visitorId | Snowflake visitor_id |
| Account ID | customer.externalId | Snowflake account_id |
| Event timestamp | product.usage.occurredAt | Snowflake occurred_at |
Martini implementation pattern
Martini retrieves a bounded date range or processes a documented export, validates time zones and aggregation definitions, stages the source data, and loads curated tables into Snowflake. A watermark with an overlap window supports late-arriving activity, while batch identifiers and idempotent writes support safe retries.
Martini capabilities used
- Scheduled workflows
- REST API consumption
- File or export processing
- JSON handling
- Data transformation
- SQL database connectivity
- Watermarks and idempotency
- Monitoring and error handling
Pattern 3: Route supported Pendo callbacks to operational workflows
When to use this pattern
Use this pattern when a required Pendo event is covered by Pendo's documented webhook functionality and downstream teams need near-real-time action. Polling remains necessary for activity that Pendo does not expose through callbacks.
Integration direction
Example Mapping
| Pendo Field | Canonical Field | Target Field |
|---|---|---|
| Event type | notification.type | ServiceNow task type |
| Account ID | customer.externalId | ServiceNow customer reference |
| Visitor ID | customer.user.externalId | ServiceNow affected user |
| Event timestamp | notification.occurredAt | ServiceNow opened or detected time |
Martini implementation pattern
A Martini webhook-triggered workflow validates the callback, checks the event type, and retrieves additional Pendo data if needed. Business rules determine whether to create or update a ServiceNow task, while a deduplication key, retry policy, and dead-letter or review path handle repeated delivery and downstream failures.
Martini capabilities used
- Webhook consumption
- Request validation
- Workflow orchestration
- API consumption
- Business rules
- Data mapping
- Idempotency
- Error handling and retries
Pattern 4: Expose a normalized Pendo API for internal consumers
When to use this pattern
Use this pattern when several internal applications need Pendo Accounts, Visitors, Guides, or usage data without each application implementing Pendo authentication, pagination, filtering, and response interpretation.
Integration direction
Example Mapping
| Pendo Field | Canonical Field | Target Field |
|---|---|---|
| Pendo Account ID | account.id | Normalized API accountId |
| Pendo Visitor ID | visitor.id | Normalized API visitorId |
| Guide activity | engagement.guideActivity | Normalized API engagement |
| Product usage data | productUsage.metrics | Normalized API usage |
Martini implementation pattern
Martini exposes a controlled REST API backed by workflows that validate caller access, apply account and time-range rules, call Pendo, handle pagination, and return a stable internal schema. Pendo-specific authentication, API changes, retries, and filtering remain centralized in the Martini implementation.
Martini capabilities used
- REST API exposure
- Authentication and authorization
- Workflow orchestration
- API consumption
- Data mapping
- Business rules
- Error handling
- Reusable integration logic
Applications commonly integrated with Pendo
Pendo data can be combined with CRM, customer-success, support, collaboration, development, finance, and analytics platforms. The exact direction and object coverage depend on the target application and the Pendo subscription or integration features in use.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Combine Pendo product adoption, account engagement, and guide activity with CRM account, opportunity, and customer-success information. | Pendo → Martini → Salesforce | A scheduled Martini workflow retrieves Pendo Accounts, Visitors, usage indicators, and guide activity, maps stable Pendo identifiers to Salesforce account and user fields, applies matching rules, and performs idempotent updates. Salesforce identifiers or attributes can optionally be sent back to Pendo where the relevant API and business process support it. |
| HubSpot | Enrich marketing and customer-success records with product usage, engagement, and account signals. | Pendo → Martini → HubSpot | Martini can extract Pendo account and visitor data, normalize usage attributes, resolve identity using maintained cross-references, and write selected signals to HubSpot. Reverse synchronization should be limited to attributes and endpoints confirmed for the particular Pendo and HubSpot configuration. |
| Jira | Relate product feedback, adoption issues, and customer-impact signals to development work and prioritization. | Pendo → Martini → Jira | A Martini workflow can receive a supported Pendo notification or run on a schedule, retrieve the relevant Pendo context, apply routing and severity rules, and create or update Jira issues. Duplicate detection should use a Pendo identifier or maintained cross-reference. |
| Zendesk | Combine product usage and guide engagement with support activity to identify adoption issues and prioritize customer assistance. | Pendo → Martini → Zendesk | Martini can retrieve Pendo visitor, account, and activity data, match it to Zendesk users or organizations, and enrich selected support workflows. Since specific native coverage was not confirmed, the integration should use the documented Zendesk API and Pendo REST endpoints. |
| Slack | Send selected product feedback, adoption alerts, or operational notifications to product and customer-success teams. | Pendo → Martini → Slack | Martini can receive a supported Pendo callback or identify a condition during scheduled extraction, evaluate notification rules, format a concise message, and call an approved Slack endpoint. Delivery should be retried without duplicating alerts. |
| Snowflake | Centralize Pendo product usage and account analytics with subscription, CRM, and support data. | Pendo → Martini → Snowflake | Martini can call Pendo analytics endpoints or process a documented Pendo export, normalize time periods and identifiers, and write staged and curated data to Snowflake through supported database or API access. Watermarks and replayable batches support reliable incremental loading. |
| NetSuite | Compare product adoption and account information with subscription, billing, and renewal data. | NetSuite → Martini → Pendo | Martini can retrieve account or subscription attributes from NetSuite, map them to Pendo Accounts where the relevant Pendo endpoints support the update, and separately extract Pendo usage data for billing or renewal analysis. Cross-reference tables prevent identity mismatches. |
| ServiceNow | Route product adoption or customer-impact signals into service-management workflows and operational reporting. | Pendo → Martini → ServiceNow | Martini can transform selected Pendo account, visitor, feedback, or usage signals into ServiceNow requests or task data, apply assignment rules, and handle retries and duplicate prevention. The implementation uses the documented APIs of both systems rather than assuming universal native coverage. |
How to build a Pendo integration in Martini
Objective
Establish authenticated access to Pendo without embedding credentials in workflow source code.
Instructions in Martini
- Create or obtain a Pendo integration key with the required permissions.
- Store the key in Martini environment configuration or secrets management.
- Configure the Pendo request with the X-Pendo-Integration-Key header.
- Confirm endpoint-specific access and account restrictions before production use.
Objective
Select the execution model that matches the Pendo capability and business latency requirement.
Instructions in Martini
- Use a scheduler for polling, incremental extraction, or regular analytics loads.
- Use a webhook-triggered workflow only for documented Pendo callback events.
- Expose a Martini API when internal applications need a controlled Pendo-facing interface.
- Define an overlap window or replay strategy for scheduled synchronization.
Objective
Collect Pendo objects and activity using bounded, restartable requests.
Instructions in Martini
- Call the required Pendo REST endpoint or consume a documented export.
- Apply supported account, date, or activity filters.
- Follow the endpoint-specific pagination model.
- Store the last successful page, cursor, event identifier, or time watermark.
Objective
Coordinate retrieval, enrichment, transformation, target writes, and failure paths in a maintainable workflow.
Instructions in Martini
- Separate request, pagination, mapping, validation, and delivery stages.
- Retrieve additional Pendo data when a webhook contains only a notification.
- Route different Pendo object types or event types through explicit business branches.
- Keep the workflow bounded with execution and page limits.
Objective
Convert Pendo-specific objects and analytics into the canonical model required by downstream systems.
Instructions in Martini
- Map Visitors, Accounts, Pages, Features, Guides, and Track Events using stable identifiers.
- Normalize timestamps, time zones, aggregation periods, and optional fields.
- Maintain cross-reference data when Pendo identifiers do not equal target identifiers.
- Validate required fields before downstream writes.
Objective
Ensure only relevant, authorized, and correctly classified Pendo data reaches each destination.
Instructions in Martini
- Filter by account, date range, event type, or product area where supported.
- Apply identity matching and account ownership rules.
- Distinguish raw usage, aggregated analytics, guide activity, and custom Track Events.
- Define duplicate, late-arriving, and rejected-record behavior.
Common Pendo data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Visitors | Represent individual users whose product usage, guide interactions, feedback, and activity are analyzed. | Salesforce, HubSpot, Zendesk, Snowflake | Martini retrieves Visitors through Pendo APIs, resolves stable identifiers and selected attributes, applies identity-matching rules, and performs idempotent downstream updates. |
| Accounts | Represent organizations or customer groups associated with Visitors and account-level product adoption. | Salesforce, HubSpot, NetSuite, Snowflake | Martini synchronizes Accounts using Pendo account identifiers, maintained cross-references, filters, and upsert logic. Account attributes can be enriched before writing to downstream systems. |
| Pages | Represent product locations or screens tracked for product usage analytics. | Snowflake, product analytics stores, internal APIs | Martini extracts Pages with usage context, normalizes names and identifiers, and stores them with extraction timestamps or exposes them through a controlled internal API. |
| Features | Represent product capabilities or UI elements tracked for usage analysis. | Snowflake, Salesforce, product operations platforms | Martini maps Features to canonical product and adoption models, applies filtering rules, and combines them with Account or Visitor activity before delivery. |
| Guides | Represent in-app messages, walkthroughs, tooltips, and other guidance experiences. | Salesforce, Zendesk, Snowflake, Slack | Martini retrieves Guide metadata or activity where available, maps engagement indicators to downstream schemas, and routes selected changes or alerts using business rules. |
| Track Events | Represent custom application events sent to Pendo for product usage analysis. | Snowflake, customer-success platforms, internal analytics systems | Martini can process Track Event data exposed through Pendo APIs or exports, preserve event timestamps and identifiers, normalize event names, and load it into analytical or operational destinations. |
Authentication and security considerations
Integration-key authentication
Pendo public REST API access uses an integration key or API key, commonly supplied through the X-Pendo-Integration-Key request header. OAuth 2.0 was not confirmed as the primary public API method.
Secret management
Store the Pendo key in Martini environment configuration or secrets management rather than workflow source code. Limit access to the environments and services that require it.
Webhook protection
For supported Pendo callbacks, confirm the applicable verification mechanism and validate signatures, shared secrets, timestamps, or other request attributes before processing.
Data protection
Product usage and visitor data should be handled according to organizational retention, privacy, and access-control requirements. Logs should exclude API keys and unnecessary sensitive visitor information.
Operational considerations for Pendo integrations
Rate limits and pagination
Confirm current Pendo quotas and endpoint restrictions. Use controlled concurrency, bounded pages, filters, and incremental windows instead of repeated full-history extraction.
Retries and idempotency
Retry transient HTTP failures and throttling responses with appropriate backoff. Use Pendo identifiers, event identifiers, timestamps, or composite keys to prevent duplicate downstream writes.
Schema evolution
Validate optional and required fields before mapping. Isolate Pendo-specific mappings from downstream schemas and monitor Pendo documentation for API versions and deprecations.
Analytics interpretation
Distinguish raw usage, aggregated analytics, guide interactions, and Track Events. Confirm time zones, aggregation periods, filters, and inclusion rules before combining metrics.
Testing and observability
Test representative Accounts, Visitors, activity windows, callback payloads, pagination, and error responses. Capture correlation data, failed identifiers, watermarks, and replay information without logging secrets.
Why use Martini instead of scripts or point-to-point integrations?
Centralized integration logic
Martini centralizes Pendo authentication, pagination, filtering, transformation, business rules, retries, and target delivery instead of duplicating them across scripts or applications.
Flexible execution models
Workflows can support scheduled extraction, supported webhook callbacks, batch processing, and API-led access while keeping the implementation adaptable to Pendo data coverage and subscription constraints.
Maintainable mappings
Mappings and reusable workflow logic isolate Pendo-specific response formats from Salesforce, data warehouse, support, and internal API schemas.
Operational control
Martini provides structured error handling, validation, monitoring, and replay-oriented processing for rate limits, pagination failures, duplicate delivery, schema changes, and downstream outages.
Frequently asked questions
Pendo can be integrated through its REST APIs for Visitors, Accounts, product metadata, usage data, guides, and analytics. Selected documented events can use webhook-style callbacks, while export and synchronization capabilities can support larger analytical datasets. Scheduled workflows are appropriate for pagination, incremental extraction, transformation, and delivery to enterprise applications or data platforms.
Yes. Martini can integrate with Pendo by consuming its REST APIs, receiving supported webhook callbacks, and orchestrating scheduled synchronization workflows. Martini can map Pendo data into downstream applications, databases, files, warehouses, or a normalized internal API.
No. A dedicated Pendo connector is not required. Martini can use Pendo's confirmed native integration mechanisms, including REST APIs, integration-key authentication, selected webhook callbacks, and documented export or synchronization capabilities.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Pendo. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Pendo, cloud infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
Pendo REST APIs should be treated as the primary server-side integration method. Use selected webhook callbacks when the required event is documented and available, and use Pendo export or synchronization capabilities for suitable analytics or higher-volume datasets. Pendo GraphQL and SOAP APIs were not confirmed.
Martini can receive the Pendo webhook-style notifications that Pendo documents and makes available for the relevant account or feature. Coverage is event-specific rather than universal, so scheduled API polling or export processing may still be required for activity not exposed through callbacks.
A Martini workflow can follow Pendo's documented pagination model, store a watermark or page state, and process bounded time windows. Stable Pendo identifiers, event identifiers, timestamps, overlap windows, and idempotent upserts help handle late-arriving data, retries, and duplicate webhook delivery.
Yes. Martini can expose a controlled REST API backed by workflows that call Pendo, apply authentication and authorization, enforce filtering and business rules, handle pagination and retries, and return a normalized schema to internal applications.
Related Martini documentation
Pendo APIs
Connect Pendo with Martini
Use Martini to build maintainable Pendo integrations that combine REST APIs, supported callbacks, scheduled workflows, secure authentication, data transformation, and reliable delivery to enterprise systems.