Jepto
Analytics & DataConnect AI agents to Jepto, a marketing intelligence platform that centralizes channel data. Agents manage clients, read the insights that anomaly detection, budget tracking, and KPI forecasting produce, and acknowledge or resolve each one.
What This Integration Enables
Jepto's useful idea is that the analysis happens on their side. Anomaly detection, KPI forecasting, and budget pacing run as configured jobs, and what they produce is an insight, which is a piece of work that has already been done. That inverts what an integration is for. This connector is not a metrics pipe you build charts from, it is a queue reader: the agent's job is to pick up findings, decide which client and which person they belong to, and route them somewhere a human will actually see them. FlowRunner agents list, search, and retrieve the clients in the account and create new ones; list insights across the account or for a single client filtered by type and resolved state, count them, retrieve one in full, find insights by an external identifier, acknowledge them, resolve or unresolve them, and attach an external ID for two-way linking with a ticketing system; read the anomaly detection jobs, budget tracking jobs, and KPI forecasting jobs that were configured in Jepto; and read the available advertising metrics for a client and data source.
Two boundaries are worth stating plainly. The detection jobs are readable but not writable through this connector: List Anomaly Detectors, Get Anomaly Detector, List Budgets, Get Budget, List KPIs, and Get KPI return the configuration of jobs that were set up in Jepto, and there is no operation here that creates or edits a detector, a budget, or a KPI target. The agent reads what a person configured and acts on what it produces. And there are no triggers. Nothing in Jepto starts a FlowRunner flow, so change detection is a scheduled poll: call Count Insights with the filters you care about to decide whether there is anything to do, then call List Insights when there is. That pattern keeps a five-minute poll across a hundred clients cheap. Every operation runs against a single Jepto account identified by an account ID, and the service talks to Jepto's public GraphQL API. The connector is built and verified against Jepto's official API.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Budget Pacing That Reaches Someone Before the Month Ends
An agency manages paid media across many clients, each with a monthly budget. On a schedule, the agent calls Count Insights filtered to budget insights and unresolved state to see whether anything needs attention, then calls List Insights and Get Insight Details for each one. It calls Get Client to resolve the client name and Get Budget to pull the tracked budget the insight refers to. It posts to the account lead in Slack with the client, the budget, the pace, and the projected overspend or underspend. Pacing problems are cheap to fix in week two and expensive to explain in week five, and the difference between those is whether anyone was told.
Insights That Become Tickets and Stay Linked
Findings that need work should not live in an alerting tool. The agent calls List Insights for unresolved anomalies, calls Get Insight Details for the full context, and creates a ticket in Linear or Jira carrying the client, the metric, and the deviation. It then calls Add External ID to Insight with the ticket key, which makes the link two-way, and calls Acknowledge Insight so the queue reflects that this one has been picked up. When the ticket closes, a second flow calls Search Insight by External ID to find the insight again and resolves it against the actual outcome rather than against a timer.
A New Client Wired Up on Day One
A new account is won. The agent calls Search Clients to confirm no record already exists, calls Create Client with the name, domain, and the labels the agency uses for segmentation, and calls Get Ads Metrics for the client and each connected data source to confirm which advertising metrics are actually available. It writes the client record and the available metric list into the onboarding document in Notion so the strategist configuring detectors and KPI targets knows what can be measured before deciding what to promise.
Human-in-Loop Highlight
Jepto ships two operations that look adjacent and mean completely different things, and the gate lives exactly on the line between them. Acknowledge Insight marks an insight as seen. Resolve or Unresolve Insight marks it as dealt with. An agent can safely own the first, because acknowledging is a statement about the agent, that it read the insight and routed it. It cannot safely own the second, because resolving is a statement about the world, that a spend anomaly was investigated and turned out to be fine, or that a budget was corrected. An agent that auto-resolves after routing is not closing findings, it is producing a clean queue that means nothing, and the failure is invisible by construction: a resolved insight is one nobody will look at again. The next person to notice is the client, at the point where an anomaly that was marked handled turns out to be a campaign that ran three weeks at the wrong bid. So the agent acknowledges freely and never resolves on its own. It posts to the account lead: "Insight [id] on client [name], type [anomaly or budget or KPI], detector [name]. Detail: [metric, expected range, observed value, period]. Acknowledged and routed to [ticket]. Resolve as expected variance, leave open pending the ticket, or escalate?" The lead answers, and the agent calls Resolve or Unresolve Insight with that answer, or leaves it open. The unresolve half of that same operation is what makes the arrangement safe: a lead who resolves something in error can have the agent reopen it, and Search Insight by ID or by External ID is how it finds it again. Reading, counting, routing, and linking run unattended across a hundred clients. Declaring a finding handled is human-in-the-loop work, because it is the only operation here that stops anyone looking.
Agent Capabilities
19 actionsClients
4- List Clients Lists all clients, meaning managed accounts, in the Jepto account, with resource totals. Paginated. Used to iterate an agency's whole book in a scheduled sweep.
- Search Clients Searches clients by name or domain. Used to resolve an inbound name to a client ID, and to check for an existing record before creating one.
- Get Client Retrieves a single client by client ID. Used to attach a human-readable client name to an insight before it is routed.
- Create Client Creates a new client with a name and domain, and optional labels. Used to onboard an account from a CRM win without retyping it.
Insights
8- List Insights Lists insights across the account or for a single client, filtered by type and by resolved state. Paginated. Insights are the notifications Jepto generates from anomaly detection, automations, and KPI forecasting.
- Get Insight Details Retrieves the full detail of a single insight. Used to turn a queue entry into a message a person can act on without opening Jepto.
- Count Insights Returns the number of insights matching optional filters. Because there are no triggers, this is the cheap first call in a scheduled poll: it lets a flow skip the run entirely when the queue is empty.
- Search Insight by External ID Finds insights linked to an external system by their external ID. Used to find the insight again when the ticket it produced is closed.
- Search Insight by ID Retrieves a single insight by insight ID, client, and job type.
- Acknowledge Insight Marks an insight as acknowledged. This records that the insight was seen and routed, which is a statement an agent can safely make about itself.
- Resolve or Unresolve Insight Marks an insight resolved, or reopens a resolved one. Resolving declares that a finding was dealt with and stops anyone looking at it again, which is why it belongs behind a human decision. The unresolve half is what makes a mistaken resolution recoverable.
- Add External ID to Insight Attaches an external identifier to an insight for two-way linking. Used to bind an insight to the ticket that was raised from it.
Anomaly Detection
2- List Anomaly Detectors Lists the anomaly detection jobs configured in the account. Paginated. Read-only: detectors are configured in Jepto, not through this connector.
- Get Anomaly Detector Retrieves a single anomaly detector by sort key. Used to name and explain the detector that produced an insight.
Budgets
2- List Budgets Lists the budget tracking jobs, optionally scoped by client. Paginated. Read-only.
- Get Budget Retrieves a single budget by sort key. Used to attach the tracked budget to a pacing insight so the number in the alert has context.
KPIs
2- List KPIs Lists the KPI forecasting jobs, optionally scoped by client. Read-only.
- Get KPI Retrieves a single KPI by sort key. Used to report the target a forecast is measured against.
Metrics
1- Get Ads Metrics Returns the available advertising metrics for a client and data source. Used during onboarding to confirm what can actually be measured before targets are agreed.
Frequently Asked Questions
What can FlowRunner do with Jepto?
FlowRunner agents can run List Clients, Search Clients, and Get Client in Jepto, plus 16 more actions.
Does connecting Jepto to FlowRunner require OAuth?
No. Jepto connects to FlowRunner with an API key, no OAuth flow required.
Can Jepto trigger a FlowRunner workflow automatically?
Jepto doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Jepto
$100 in credits. No card required. Connect in minutes.