Smartlook
Analytics & DataConnect AI agents to Smartlook, a session replay and product analytics platform. Agents read sessions, events, and visitor records, pull funnel data, and manage webhook subscriptions for downstream systems.
What This Integration Enables
Session replay is the one analytics category where the underlying record is not a number. It is a reconstruction of a real, often identified person using your product, including what they typed, where they hesitated, and what they gave up on. Smartlook is built for teams who believe the aggregate is where the question starts and the recording is where it gets answered. This connector is shaped around that belief. It is almost entirely a read surface, and the reading goes in both directions: from the aggregate down to the individual, and from the individual back up.
Downward, Get Funnel Details computes a funnel's conversion analysis over a date range and reports, for each step, the visitor count and the percentage retained from the previous step. Get Funnel Drop-Off Visitors then hands back the actual visitor IDs at a chosen step, either the ones who continued or the ones who left. Upward, Get Visitor returns a single person's identification and aggregate counts, Get Visitor Sessions lists their recordings, and Get Visitor Events lists what they did, optionally scoped to one session. Search Sessions and Search Visitors take an array of filter conditions, each a field name, an operator, and a value, so a flow can express the same query an analyst would have built in the dashboard and run it on a schedule instead.
Two things to be clear about before building. Smartlook has no triggers. The webhook actions on this connector are administrative: Create Webhook subscribes a URL of your choosing at Smartlook and returns a webhook ID, Update Webhook rotates its secret or disables it, Delete Webhook removes it. None of them creates a FlowRunner trigger, and Smartlook does not push into a flow as a result. A flow that needs to react starts from a schedule, from a deploy, or from another system, and reads Smartlook when it gets there. Second, this connector reads people. Sessions carry visitor identification, device, browser, and geography, and the funnel actions return visitor IDs by name of the thing they failed to do. Treat the output as personal data throughout, because it is.
Without FlowRunner
With FlowRunner
Use Case Scenarios
The funnel step that moved, with the recordings attached
A nightly flow calls List Funnels to resolve the checkout funnel by name, then Get Funnel Details over yesterday with Wait For Finish set so the computation completes before the flow continues. The agent compares each step's retention against the trailing week. When a step drops beyond the tolerance the team agreed on, it calls Get Funnel Drop-Off Visitors for that step with the success flag set to return the visitors who left, then Get Visitor Sessions for each of them to collect the dashboard URLs. The summary that lands in Slack is not "conversion is down". It names the step, the size of the move, and lists the sessions that make up the difference, so the first person to open it is already looking at the right five recordings.
Bug reports that arrive with evidence
A support ticket in Zendesk says a customer could not complete a form. The agent takes the customer's identifier from the ticket and calls Search Visitors with a filter condition matching it, then Get Visitor Events filtered to the relevant date range and event types, and Get Visitor Sessions for the recordings on either side of the failure. It writes the event sequence and the timestamps back onto the ticket, and files an issue in Jira containing the same sequence. The support agent no longer has to ask a frustrated customer to describe what they clicked, and the engineer picking up the issue starts from an ordered list of what actually happened rather than a paraphrase of it.
Watching the events that only matter after a release
After a deploy, a flow calls List Events to resolve the tracked events for the feature that shipped, then Get Event Details over the hours since release for each one, returning total occurrences, unique visitors, new visitors, and average occurrences per visitor. It calls Get Event Visitors on any error event that appears at all, and Get API Usage Stats between batches, because Smartlook's rate limit is hourly and a release-day loop is exactly the shape that exhausts it. The result is posted to the release thread with the previous release's numbers beside it. Nothing here is a judgment yet. It is the set of facts a judgment would need.
Human-in-Loop Highlight
Get Session Public Link generates a shareable public link for a session recording so it can be viewed without a Smartlook account, and that sentence is the whole risk. Every other read on this connector returns data into a flow that stays inside your systems and inside your access controls. This one takes a recording of a named person using your product and produces a URL that works for anyone who holds it, including anyone the first recipient forwards it to. There is no revoke action anywhere in this connector's surface, so the flow that creates the link cannot take it back, and the person in the recording never agreed to this particular audience. It is genuinely useful, which is why it is worth stopping on rather than removing: a support engineer explaining a defect to a vendor, or a designer showing a stakeholder without a seat, is a real and reasonable need. So the agent does the work that has no judgment in it and stops at the part that does. It resolves the drop-off, pulls the candidate sessions, and posts the shortlist to the product owner in Slack with the visitor identification each recording carries: "Three sessions match the checkout failure on step 4. Two are identified users with email addresses attached, one is anonymous. Generate a public link for any of these, and if so which?" The owner picks, or picks none and sends a dashboard URL to someone who already has access instead. Treating that as a human-in-the-loop gate is not caution for its own sake. It is the difference between an agent that can be trusted with a standing schedule against your session data and one that has to be run by hand every time.
Agent Capabilities
19 actionsProject
2- Get Project Info Returns the project and organization the configured API token is scoped to, including organization ID and name and project ID and name. Use it as the first call in a flow to confirm the token points at the project you think it does, since Smartlook tokens are per project.
- Get API Usage Stats Returns current API usage for the project with a per-endpoint breakdown. Smartlook's rate limit is hourly and depends on plan, so a batch flow should read this between passes rather than discovering the ceiling by hitting it.
Sessions
3- Search Sessions Searches session recordings using an array of filter conditions, each with a field name, an operator, and a value. Returns matching sessions with visitor identification, device, browser and geo details, duration, page URLs, notes, and a dashboard URL, with cursor based pagination via the after cursor.
- Get Session Retrieves the full details of one session recording by its ID, including visitor identification, device, browser and geo metadata, duration, landing and exit pages, visited URLs, and the dashboard URL where the recording can be watched.
- Get Session Public Link Generates a shareable public link for a session recording so it can be viewed without a Smartlook account. This is the only action here that moves a recording outside your access controls, and nothing in this connector revokes it.
Events
3- List Events Lists the tracked events defined in the project, such as clicks, custom events, and errors, each with its ID, name, and category. Supports cursor based pagination and optional filtering by event category.
- Get Event Details Retrieves aggregated statistics for a single event over a required date range, including total occurrences, unique and new visitors, average occurrences per visitor, and an optional occurrence histogram.
- Get Event Visitors Returns the visitors who triggered a specific event within a required date range, with each visitor's identification, first and last seen timestamps, total visits, and how many times they matched the event.
Visitors
4- Search Visitors Searches visitors using an array of filter conditions. Returns matching visitors with identification, first and last seen timestamps, and links to their sessions and events, with cursor based pagination via the after cursor.
- Get Visitor Retrieves one visitor by ID, including identification data, first and last seen timestamps, and aggregate counts of visits, sessions, and events.
- Get Visitor Sessions Lists the session recordings belonging to a specific visitor, with duration, device, browser and geo metadata, landing and exit pages, and dashboard URLs. Supports cursor based pagination.
- Get Visitor Events Lists the events one visitor triggered, optionally filtered by date range, event types, or a single session. Each event includes its type, page URL, timestamp, and any recorded properties.
Funnels
3- List Funnels Lists the conversion funnels defined in the project, each with its ID, name, and ordered list of step events. Use it to resolve a funnel by name before computing it.
- Get Funnel Details Retrieves a funnel with its computed conversion analysis over a required date range, including the overall conversion rate and, per step, the visitor count and percentage retained from the previous step. Set Wait For Finish to block until the computation completes.
- Get Funnel Drop-Off Visitors Returns the visitor IDs at a specific funnel step over a date range, either those who continued to the next step or those who dropped off, selected with the success flag. This is the action that turns a percentage into a list of people to go and watch.
Webhooks
4- List Webhooks Lists all webhook subscriptions configured for the project, each with its ID, target URL, type, and enabled state.
- Create Webhook Creates a webhook subscription that pushes notifications to a URL you supply when the selected resource changes, and returns the new webhook ID. When a secret is provided, Smartlook signs each payload with an HMAC-SHA256 signature in the Smartlook-Signature-256 header. This subscribes an endpoint of your choosing at Smartlook and does not create a FlowRunner trigger.
- Update Webhook Updates an existing webhook subscription, changing its target URL, rotating its signing secret, or enabling and disabling it. Returns the webhook ID.
- Delete Webhook Permanently deletes a webhook subscription so it stops delivering payloads. Returns an empty object on success.
Frequently Asked Questions
What can FlowRunner do with Smartlook?
FlowRunner agents can run Get Project Info, Get API Usage Stats, and Search Sessions in Smartlook, plus 16 more actions.
Does connecting Smartlook to FlowRunner require OAuth?
No. Smartlook connects to FlowRunner with an API key, no OAuth flow required.
Can Smartlook trigger a FlowRunner workflow automatically?
Smartlook doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Smartlook
$100 in credits. No card required. Connect in minutes.