Ellipse Gradient for Header

FullStory Integration Guide

Connect FullStory digital experience data with enterprise systems through REST APIs, exports, event ingestion, and orchestrated Martini workflows.

FullStory integration options at a glance

FullStory provides documented REST APIs for working with users, sessions, events, and related digital experience data. Its export capabilities can support larger or asynchronous data extractions, subject to the selected product, plan, retention policy, and endpoint behavior. FullStory also supports application instrumentation and server-side or API-based event ingestion for supported use cases. Universal webhooks for all FullStory events are not confirmed, although selected features may provide callbacks. Martini can authenticate with FullStory API keys, schedule extraction workflows, poll export jobs, paginate results, transform JSON or files, submit supported ingestion payloads, and load normalized data into databases, warehouses, or operational applications.

Integration pointSupported by FullStory?Common use casesHow Martini supports it
REST APIsYesRetrieve or work with FullStory Users, Sessions, Events, Pages, Segments, and related data where the selected API and account permissions allow it.Martini consumes REST endpoints, supplies API-key authentication, handles pagination and filtering, transforms JSON, and writes results to downstream systems.
AuthenticationYesFullStory documents API-key-based authentication for API access, with permissions controlled at the organization or account level.Martini stores API keys in secrets or protected environment configuration and applies them to outbound HTTPS requests.
Bulk / async / batch APIsLimitedFullStory export capabilities may support larger or asynchronous extractions using jobs, polling, pagination, time windows, or downloadable results.Martini can orchestrate export requests, status polling, file retrieval, partitioning, checkpointing, and restartable loads.
File / export deliveryLimitedExports may produce downloadable or file-based output, but a general-purpose attachment API was not confirmed.Martini can read documented export output, transform file or JSON content, and load it into databases or warehouses.
Database / analytics accessLimitedFullStory supports exporting behavioral data for analytics use cases; direct SQL access to FullStory-managed databases was not confirmed.Martini can load API or export results into supported SQL databases or warehouses without requiring direct access to FullStory storage.
Event ingestionLimitedFullStory supports application instrumentation and server-side or API-based ingestion for supported event and user-identification scenarios.Martini can receive upstream business events, map them to the documented FullStory payload, and submit them over HTTPS with retry and idempotency controls.
Webhooks / outbound callbacksLimitedSelected FullStory products or integration features may provide callbacks, but a universal stream for all Users, Sessions, Pages, or Events was not confirmed.Where a callback is documented, Martini can expose a REST endpoint, validate requests, deduplicate notifications, and route them to workflows.
SDKsYesFullStory client-side SDKs and instrumentation libraries collect supported user, session, and application data.Martini does not replace client instrumentation; it can orchestrate server-side APIs, ingestion, exports, and downstream processing around that data.

How FullStory exposes data and business events

FullStory REST APIs

FullStory documents REST API access for working with digital experience data. Available objects, fields, filters, and permissions depend on the selected API and account configuration.

Martini implementation pattern

Martini authenticates with a protected FullStory API key, invokes the relevant REST endpoint, handles pagination and rate limits, validates the response, maps JSON into a canonical model, and writes it to the target system.

Implementation sequence

Authenticate with a protected FullStory API key
Call the documented FullStory REST endpoint
Follow pages, cursors, or continuation positions
Validate and transform the JSON response
Write the result and persist the extraction checkpoint

FullStory data exports

FullStory export capabilities can support larger or asynchronous extraction, depending on product area, plan, retention, and endpoint behavior. Results may be returned synchronously, through an export job, or as a downloadable file.

Martini implementation pattern

Martini schedules an export workflow, requests the documented export, polls when required, retrieves the resulting data, partitions large windows, and loads restartable batches into a warehouse or database.

Implementation sequence

Start the scheduled extraction window
Request the documented FullStory export
Poll the export status when the operation is asynchronous
Retrieve the resulting JSON or file output
Load normalized batches and store the completed window

FullStory event ingestion

FullStory supports application instrumentation and server-side or API-based event ingestion for supported use cases. The exact endpoint, event types, identifiers, and required fields must be confirmed for the selected integration.

Martini implementation pattern

Martini receives an event from an application or internal API, validates and maps it to the documented FullStory ingestion model, submits it over HTTPS, and retries transient failures without creating duplicates.

Implementation sequence

Receive the upstream business event
Validate required FullStory identifiers and properties
Map the event to the supported ingestion payload
Submit the payload over HTTPS
Record the outcome and retry transient failures

Selected FullStory callbacks

A universal FullStory webhook stream for all sessions, users, pages, and events was not confirmed. Selected products or integration features may provide event delivery or callbacks.

Martini implementation pattern

If the selected FullStory feature documents a callback, Martini exposes a REST endpoint, validates the request, checks for duplicate delivery, and routes the accepted event to downstream processing. Otherwise, scheduled REST retrieval is used.

Implementation sequence

Expose the Martini callback endpoint when the feature supports one
Validate the callback authentication and payload
Check the event or delivery identifier for duplicates
Route the accepted notification to a workflow
Use scheduled API retrieval when no callback is available

Common FullStory integration patterns

Pattern 1: Load FullStory activity into a data warehouse

When to use this pattern

Use scheduled extraction when product, customer, and behavioral data must be analyzed together. This pattern is appropriate for Snowflake or Google BigQuery loads where the account exposes the required REST or export capabilities.

Integration direction
FullStory
Martini
Snowflake
Example Mapping
FullStory FieldCanonical FieldTarget Field
userIdsource_user_iduser_id
sessionIdsource_session_idsession_id
eventTypeactivity_typeevent_type
timestampoccurred_atoccurred_at
Martini implementation pattern

A scheduler starts the workflow for a bounded time window. Martini retrieves or downloads data, follows pagination or export-job status, validates schemas, maps objects into warehouse tables, applies an overlap window, and records the source window and checkpoint. Malformed rows are quarantined while transient failures are retried.

Martini capabilities used
  • workflows
  • scheduled triggers
  • API consumption
  • data mapping
  • JSON handling
  • business rules
  • error handling

Pattern 2: Enrich Salesforce customer activity with FullStory sessions

When to use this pattern

Use this pattern when service or customer-success teams need permitted digital-session context alongside Salesforce Contacts, Leads, Accounts, or Cases.

Integration direction
FullStory
Martini
Salesforce
Example Mapping
FullStory FieldCanonical FieldTarget Field
userIdcustomer_identifierContact.External_Id__c
sessionIdsession_referenceFullStory_Session__c
sessionStartactivity_started_atLast_Digital_Activity__c
eventTypebehavior_signalDigital_Signal__c
Martini implementation pattern

Martini retrieves selected Users or Sessions, resolves identities using a stable business identifier rather than email alone, applies privacy and minimum-field rules, and updates Salesforce. Identity mismatches go to a review path, while duplicate updates are controlled by source identifiers.

Martini capabilities used
  • API consumption
  • identity resolution
  • data mapping
  • business rules
  • validation
  • error handling

Pattern 3: Route FullStory signals to Jira and Slack

When to use this pattern

Use this pattern for selected error or product-friction signals that should create engineering work or notify a team. Because universal FullStory webhooks were not confirmed, scheduled polling may be required.

Integration direction
FullStory
Martini
Jira
Slack
Example Mapping
FullStory FieldCanonical FieldTarget Field
eventTypesignal_typeJira.Issue_Type
sessionIdsession_referenceJira.Description
errorCountthreshold_valueJira.Priority
pageUrlaffected_locationSlack.Message
Martini implementation pattern

A scheduled workflow retrieves selected Events or consumes a documented callback, evaluates event names and thresholds, deduplicates by event or signal key, and routes qualifying signals to Jira and Slack. Retries and a processed-signal store prevent duplicate work items or notifications.

Martini capabilities used
  • workflows
  • scheduled triggers
  • webhook consumption
  • business rules
  • data mapping
  • idempotency
  • error handling

Pattern 4: Send application events into FullStory

When to use this pattern

Use this pattern when backend milestones such as orders, subscriptions, or support outcomes need to be associated with FullStory users or sessions and the applicable FullStory ingestion API supports the required payload.

Integration direction
Application API
Martini
FullStory
Example Mapping
FullStory FieldCanonical FieldTarget Field
customerIduser_identifierFullStory.user_id
orderIdtransaction_identifierFullStory.event.order_id
statusbusiness_outcomeFullStory.event.status
occurredAtevent_timeFullStory.event.timestamp
Martini implementation pattern

Martini receives the application event through an API or workflow trigger, validates the supported FullStory identifiers and properties, maps the payload, and submits it over HTTPS. It records a deterministic event key and retries only transient failures; unsupported fields are rejected or quarantined.

Martini capabilities used
  • API exposure
  • workflows
  • data mapping
  • JSON handling
  • validation
  • retry handling
  • secrets management

Applications commonly integrated with FullStory

FullStory data can be combined with customer, support, engineering, collaboration, and analytics applications. The exact integration path depends on the FullStory APIs, export capabilities, account configuration, and permissions available to the implementation.

Application Scenario Direction Martini Pattern
Salesforce Associate customer, account, lead, or case context with selected FullStory sessions and behavioral signals. FullStory → Martini → Salesforce A scheduled Martini workflow retrieves permitted users or session metadata, resolves identities using a stable business identifier, applies privacy and field-selection rules, and updates Salesforce records with concise session context or links.
HubSpot Combine digital behavior with contact and marketing lifecycle data for customer and campaign analysis. FullStory → Martini → HubSpot Martini retrieves selected FullStory activity, maps identifiers and approved attributes to HubSpot contacts or events, and uses validation and retry handling for API writes.
Zendesk Give support teams relevant digital-session context when investigating reported product or website problems. FullStory → Martini → Zendesk A workflow correlates FullStory users or sessions with support identities, selects minimum necessary metadata, and enriches Zendesk tickets while avoiding unnecessary session-content transfer.
Jira Create engineering work items from recurring error-related events or product-friction signals. FullStory → Martini → Jira Martini polls or receives a confirmed callback for selected signals, evaluates thresholds and duplicate rules, then creates or updates Jira issues with a permitted session reference.
Slack Notify product, support, or engineering teams about selected events and threshold breaches. FullStory → Martini → Slack A Martini workflow retrieves selected events on a schedule or consumes an available callback, applies routing rules, and sends concise Slack messages with identifiers and approved context.
Snowflake Centralize FullStory behavioral data with customer, product, and transaction data for analytics. FullStory → Martini → Snowflake Martini schedules REST or export retrieval, tracks pagination or asynchronous jobs, normalizes Users, Sessions, Events, and Pages, and loads restartable batches into Snowflake.
Segment Coordinate event collection and identity data across digital products and analytics destinations. Segment → Martini → FullStory Martini receives selected application events, maps identity and event fields to the documented FullStory ingestion model, and submits only supported payloads over HTTPS.
Google BigQuery Analyze FullStory sessions and events alongside application and transaction data. FullStory → Martini → Google BigQuery A scheduled workflow retrieves or downloads permitted FullStory exports, validates schemas, transforms data into analytical tables, and records extraction windows for repeatable loads.

How to build a FullStory integration in Martini

Objective

Establish secure access to the selected FullStory API, export, ingestion endpoint, or confirmed callback mechanism.

Instructions in Martini

  • Create a protected Martini secret for the FullStory API key.
  • Confirm organization permissions, endpoint availability, and the current authorization header requirements.
  • Separate credentials and configuration by environment.

Objective

Select the execution model that matches the FullStory capability and business latency requirement.

Instructions in Martini

  • Use a scheduler for exports, polling, and incremental synchronization.
  • Use an API or callback trigger only when the selected FullStory feature documents event delivery.
  • Define the extraction window, cursor, or checkpoint strategy.

Objective

Acquire FullStory Users, Sessions, Events, Pages, Segments, or export output reliably.

Instructions in Martini

  • Call the documented REST endpoint or request the supported export.
  • Implement pagination, filtering, status polling, and rate-limit handling as required.
  • Persist the last successful cursor, timestamp, or completed export window.

Objective

Coordinate retrieval, validation, transformation, business rules, downstream writes, and state management in one maintainable flow.

Instructions in Martini

  • Separate extraction, normalization, routing, and delivery stages.
  • Use reusable workflow logic for common authentication, pagination, and error paths.
  • Allow batches and export jobs to restart without repeating successful work.

Objective

Convert FullStory JSON or export files into the canonical and target-specific models.

Instructions in Martini

  • Map stable user, session, event, page, and segment identifiers.
  • Preserve source timestamps and extraction metadata where useful.
  • Retain or quarantine unknown fields according to the target schema policy.

Objective

Control privacy, identity matching, filtering, thresholds, and duplicate behavior before downstream delivery.

Instructions in Martini

  • Transfer only the minimum permitted FullStory context.
  • Use stable identifiers and explicit rules for anonymous-to-known identity transitions.
  • Apply event thresholds and processed-event checks before creating tickets or notifications.

Common FullStory data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
UsersRepresent identified, anonymous, or application-associated people linked to FullStory activity.Salesforce, HubSpot, Zendesk, Snowflake, Google BigQueryMartini maps permitted identifiers and attributes, applies identity-resolution and privacy rules, and deduplicates by stable source identifiers where available.
SessionsRepresent individual browsing or product-use sessions containing session metadata, pages, and events.Salesforce, Zendesk, Snowflake, Google BigQuery, JiraMartini retrieves sessions through documented APIs or exports, filters the required metadata, and links sessions to downstream users or cases when permitted.
EventsCapture user actions, application events, custom events, and selected behavioral signals.Jira, Slack, Snowflake, Google BigQuery, FullStory ingestion endpointsMartini polls or receives supported event notifications, applies thresholds and duplicate controls, and maps event properties to operational or analytical models.
PagesDescribe page views or visited application locations associated with Sessions.Snowflake, Google BigQuery, Salesforce, ZendeskMartini normalizes page attributes with session keys, preserves source timestamps where available, and loads only approved fields.
SegmentsRepresent saved groups of Users or Sessions based on behavioral or attribute-based criteria.Salesforce, HubSpot, Snowflake, Google BigQueryMartini retrieves supported segment data, maps membership or criteria to downstream audiences, and records the extraction position.

Authentication and security considerations

API-key authentication

FullStory documents API-key-based authentication for API access. Confirm the current Authorization header format, endpoint permissions, and key lifecycle against the selected FullStory API before deployment.

Secrets and permissions

  • Store FullStory API keys in Martini secrets or protected environment configuration.
  • Use separate credentials for environments and integration purposes where appropriate.
  • Restrict organization or account permissions to the data and operations required by the workflow.
  • Do not log API keys, sensitive session content, or unnecessary user attributes.

Privacy controls

FullStory data may contain sensitive behavioral and application-context information. Apply data minimization, masking, exclusion, retention, consent, and regional processing requirements before copying data to downstream systems.

Operational considerations for FullStory integrations

Throughput and extraction

  • Confirm API limits and handle HTTP 429 responses with bounded exponential backoff.
  • Implement the documented pagination, cursor, continuation-token, or export-job behavior.
  • Partition large extractions into restartable time windows and persist checkpoints.

Consistency and idempotency

  • Use overlap windows for late-arriving events and deduplicate with stable FullStory identifiers.
  • Maintain processed-event state before creating tickets, alerts, or other side effects.
  • Do not assume event timestamps alone provide a stable extraction boundary.

Schema and testing

  • Treat event properties and export formats as external contracts that can change.
  • Validate required fields, preserve unknown fields where practical, and quarantine malformed records.
  • Test authentication, pagination, rate limits, privacy rules, retries, and representative historical windows before production deployment.

Observability

Log extraction windows, source identifiers, correlation information, and workflow outcomes without exposing keys or sensitive payloads. Make export jobs and downstream loads restartable and monitor failures separately from rejected records.

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

Orchestration instead of isolated scripts

Martini provides a maintainable workflow for FullStory authentication, scheduled extraction, export polling, pagination, transformation, routing, and downstream delivery. This keeps integration state, business rules, retries, and monitoring in an explicit implementation rather than scattering them across scripts.

Reusable integration assets

Martini can expose APIs, consume REST endpoints, receive confirmed callbacks, and reuse mapping, validation, security, and error-handling logic across FullStory use cases.

Controlled enterprise delivery

Teams can normalize FullStory data once and deliver it to warehouses, databases, customer systems, or collaboration tools while applying identity, privacy, idempotency, and operational controls consistently.

Frequently asked questions

How can FullStory be integrated with enterprise systems?

FullStory can be integrated through its documented REST APIs, data export capabilities, supported event-ingestion endpoints, and selected callbacks where available. Martini can schedule retrieval, poll asynchronous exports, transform JSON or files, submit supported event payloads, and write normalized data to databases, warehouses, Salesforce, Zendesk, Jira, Slack, or other APIs.

Can Martini integrate with FullStory?

Yes. No native Martini FullStory connector is documented in the supplied materials, but Martini can integrate with FullStory through its documented REST APIs, API-key authentication, export mechanisms, supported ingestion endpoints, and any confirmed callback features.

Do I need a connector to integrate FullStory with Martini?

No. A dedicated FullStory connector is not required. Martini can consume FullStory REST APIs, orchestrate exports, submit supported ingestion payloads, and receive a callback through a Martini REST endpoint when FullStory documents one for the selected feature.

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

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

Which FullStory integration methods should an architect use?

Use the documented FullStory REST APIs for targeted retrieval and operations, and use documented export capabilities for larger or asynchronous extraction. Use the applicable ingestion API for supported server-side events. GraphQL and SOAP APIs were not confirmed, so they should not be assumed.

Does FullStory provide webhooks or callbacks for events?

A universal webhook stream for all FullStory Users, Sessions, Pages, and Events was not confirmed. Selected products or integration features may provide callbacks. If the selected feature documents one, Martini can receive and validate it; otherwise, scheduled REST retrieval is the safer synchronization pattern.

How should FullStory data be synchronized incrementally?

Use a documented cursor, export position, timestamp, or bounded time window. Add an overlap interval for late-arriving events and deduplicate with stable FullStory identifiers. Persist extraction windows and checkpoints so jobs can restart without duplicating downstream writes.

How does Martini handle FullStory mapping, errors, and duplicates?

Martini can map FullStory JSON or export files into canonical and target models, apply identity and privacy rules, validate required fields, and route malformed data for review. Workflows can distinguish authentication, authorization, rate-limit, validation, and transient errors, retry eligible failures, and use idempotency state to prevent duplicate updates.

Related Martini documentation

APIs

Workflows

Data

Security

Reliability

Connect FullStory to your enterprise systems

Use Martini to build secure, observable FullStory integrations around REST APIs, exports, supported event ingestion, and confirmed callbacks.

EXPLORE MARTINI
BOOK A DEMO