Most teams think of Fullstory as something that watches what happens in the browser or mobile app. That’s true—but it’s only part of the picture. You also have information about your users that comes from outside an app experience: backend transaction or event data, non-behavioral segmenting/targeting properties, and more. And maybe you want to activate all of this data outside Fullstory’s web UI.
Fullstory’s server APIs let you extend that picture programmatically: sending data in, pulling intelligence out, and building workflows that react to user behavior in real time. In practice, teams that get the most out of Fullstory are the ones who stop treating it as a passive observer and start treating it as an active participant in their stack. Here’s a practical look at what’s actually available today.
Enrich the context you already have
Your browser-based sessions are rich, but they don’t know everything. A checkout confirmation, a support ticket ID, a backend error that never surfaced in the UI—these things live in your systems, not in the session. Server-side events fill that gap. Using the Events API, you can create custom events tied directly to a specific session or user, and they get stitched into the existing session timeline. Your team ends up with a complete picture of what the user experienced, not just the clicks.
User data works the same way. The Users API lets you create, update, or enrich user records with custom properties—pricing plan, account tier, total spend, or any attribute that lives in your backend.
Choosing the right import pattern
There are three ways to write data into Fullstory via the API, and the right one depends on your volume and latency requirements.
For most real-time use cases—tagging a user when they complete onboarding, stitching in a server-side conversion event—the standard synchronous endpoints work fine. You POST to /v2/users or /v2/events, get a response immediately, and move on.
For high-volume or backfill scenarios, the Batch Import workflow is the right tool. It’s available for both users and events. You submit up to 50,000 records in a single request, get a job ID back, and then poll for status and errors asynchronously. It’s the pattern to reach for when you’re syncing historical data or running large-scale enrichment jobs.
There’s also a Stream Import option for users specifically—a fire-and-forget pattern that returns a request ID immediately and processes the record asynchronously in the background. It’s useful when you need to create user records without waiting on a synchronous response, but you still want the ability to check on status later via the request ID.
Across all three patterns, the API supports idempotency keys—a header you can pass on any create request to ensure that retries don’t result in duplicate records. If a network error causes you to retry a request, passing the same idempotency key guarantees the operation only executes once. Keys expire after 24 hours, so they’re not a long-term deduplication mechanism, but they’re exactly what you want for handling transient failures gracefully in production.
Pull intelligence when you need it
The Sessions API is where things get particularly interesting for teams building real-time workflows. It’s designed for real-time inspection and online inferencing, returning data within seconds of events being captured. Note that this won’t be your best option for data export or bulk transformation—that’s what Anywhere: Warehouse is for.
There are three ways to access session data programmatically, and which one you reach for depends on what you’re building.
1. If you need the raw event stream for your own custom processing, Get Session Events returns the full, untransformed capture for any session.
2. If you’re feeding session context into an LLM or AI model that you control, Generate Context does the work of lightly structuring and transforming that data for optimal consumption—so you’re not passing raw event noise into a model and hoping for the best.
3. And if you want Fullstory’s AI to generate the summary itself, that’s what the Generate Summary endpoint is for. You define a prompt profile—specifying what slice of the session to analyze, what context to include or exclude, and what format you want back (plain text or structured JSON conforming to a schema you define)—and Fullstory returns an AI-generated result built to your spec.
A support team might configure a profile that returns a plain-language description of what the user struggled with, automatically. A product team might define a JSON schema that structures session summaries into fields that pipe directly into a dashboard or alerting system. The prompt profiles are reusable and manageable via API, so once you’ve defined them, generating summaries at scale is straightforward.
Why the data flow in both directions matters
The conventional approach to behavioral data is retrospective: something goes wrong, someone pulls a report, someone watches a replay, someone files a ticket. That loop takes time—and by the time it closes, users have already churned or complained.
What this API enables is a different model, one where your systems can act on behavioral signals as they happen rather than after the fact. You’re not just giving your team visibility into what users did—you’re giving your infrastructure the ability to respond to it. The behavioral data that Fullstory captures can flow out through the Sessions API into whatever execution layer makes sense: a support platform, a personalization engine, a downstream alerting system.
That’s the practical meaning of Anywhere: Activation. It’s not a category—it’s a different operating model for how behavioral data gets used.
Getting started
All of this is available today. Authentication uses an API key with Admin or Architect permissions, and all V2 endpoints are available at api.fullstory.com/v2. For more information, explore our developer documentation.
