Triage Broken Sessions With a Meta Muse Connector for Session Analysis

An agent pulling traffic numbers and an agent triaging broken sessions do different work, and a Meta Muse connector for session analysis is the second kind. The output is not a chart but a ranked shortlist of what went wrong on your site, with recordings attached, so the agent decides what a human opens next.

The short version: three of the four session endpoints only read. Build the connector, paste a flow_ws_ workspace token into Muse's secure credential prompt, and tell it in the same message that PATCH /issues/{issueId} is off limits.

Muse writes the connector itself from a public API spec, and Parallel reported on 14 September 2026 that the code it writes runs inside the agent's own cloud runtime cell. The Meta Muse connector for web analytics guide covers that mechanism and the credential flow. This post is about pointing it at issues.

What does the connector see when Muse opens an issue?

Muse sees the issue record Flowsery produced, not the recording behind it. Flowsery's detection surfaces rage clicks, JavaScript errors, dead clicks and drop-offs, and each record carries a title, a description, a severity, a status, sessionsCount, firstSeenAt, lastSeenAt, ordered stepsToReplicate and a sampleRecordingId.

Severity takes low, medium, high and critical. A workspace token covers every website in the workspace, so each call needs websiteId or domain to name one.

GET /issues/{issueId} is the call worth teaching Muse early, because it returns the comments your team left on an issue alongside the sessions. That separates a drop-off nobody has seen from one somebody already looked at last Thursday.

Can Muse watch a session replay?

No. A replay is video shaped and the API hands back JSON, so Muse reads a structured summary of a recording rather than the recording. The closest the API gets is the occurrences array: each flagged moment carries a description, a severity and an atSeconds offset into the recording.

The practical version: Muse can tell you a rage click cluster hit 41 sessions, read you the steps to replicate it, and name the recording that shows it best. It cannot tell you the submit button looked greyed out. The browser route does not rescue this: Meta says the browser sub-agent reads an accessibility tree snapshot, not the raw DOM.

What do you paste into Muse to build the connector?

One message carrying the spec URL, the auth style and the write ban. The ban belongs in the first message rather than a later correction, because the connector Muse saves is built from what it read during setup.

Build a custom connector for Flowsery from the API reference at
https://flowsery.com/docs/api-introduction.md. It is public, so read it
without logging in. Full spec: https://flowsery.com/openapi.json.
 
Base URL: https://analytics.flowsery.com/analytics/api/v1
Auth: an "Authorization: Bearer <token>" header. I will paste the token into
the secure credential prompt, not into this chat. It starts with flow_ws_.
 
Use GET /issues, GET /issues/{issueId} and GET /visitors/{visitorId} only.
Do not call PATCH /issues/{issueId}. Start with GET /websites and list the
website IDs you can see.

The web analytics guide walks the credential prompt step by step. What changes on issues is the last paragraph: name the three reads, name the one write, forbid it. Then ask for open critical issues on one website, which exercises the read path and writes nothing.

Which session calls read, and which one writes?

Four endpoints matter and exactly one changes data: PATCH /issues/{issueId} updates an issue's status, which is the whole supervision problem.

Keep the connector read-only for the first week. Why a connector Muse wrote itself earns less isolation than a built-in one, and what Meta's approval defaults do about it, is the subject of the web analytics guide. On issues the posture costs nothing, because triage never needs the write.

Should Muse be allowed to change an issue's status?

Not in the first week, and not on a schedule after that. An agent holding PATCH /issues/{issueId} can resolve something nobody looked at, and a resolved issue leaves the list everyone opens in the morning. Suspended is worse: a suspended issue drops out of the default GET /issues response until somebody asks for status=suspended.

Status hygiene is exactly the chore an agent looks good at, and a sweep that moves twelve stale criticals to resolved produces a shorter list with the same broken checkout underneath it.

Meta says some agent actions cannot be undone and leaves the fixing to you. As of 20 September 2026 your trail is Muse's Activity log, a chronological record of actions it took and permissions you granted, so read it before you widen a grant. Allow a write once, for the issue in front of you, after you have opened the replay.

What breaks on session analysis specifically?

Five things go wrong here that do not go wrong on a reporting connector.

One rule carries over from the web analytics guide: the Muse VM sits in Meta's cloud, so anything behind your VPN or on your laptop is out of reach. For the same loop without Muse, the Grok bot template for session analysis runs the identical call chain.

Frequently Asked Questions

Does Meta Muse support MCP for session analysis?

Parallel found no "add MCP server" setting on 14 September 2026, and the web analytics guide has the full MCP answer. For triage it changes nothing: the three reads and the one write go over REST either way, and Flowsery's hosted MCP server serves Claude, Cursor and Codex instead.

Can Muse close a Flowsery issue on its own?

Only if you let it. PATCH /issues/{issueId} is the single call that moves an issue between open, in_progress, resolved and suspended, and the setup message above forbids it outright. Meta's approval prompts appear in the client UI rather than the chat, so an unexpected write is visible before it happens.

What does Muse see about a visitor?

More than a timeline. GET /visitors/{visitorId} returns an identity block with country, region, city, browser, OS, device and viewport, plus activity, revenue and a profile carrying userId, name and email once your site has called identify. The visitor id is the first-party _fs_vid value, and Flowsery stores no IP addresses and sets no cross-site identifiers. Decide whether Muse should hold that before you create the token.

Does this replace opening the replay?

No. The connector ranks and narrows, and the recording is where the reason lives. Let Muse pick the three sessions worth ten minutes, then spend the ten minutes. Aggregate questions belong on the web analytics side of the same connector.

Which Flowsery plan do I need?

Either one. GET /issues and the AI session analysis behind it sit on both Team at $250 a month and Pro at $500 a month, and both open with a 14-day free trial that needs no card. The web analytics guide breaks down the seat, website and replay-retention limits that separate them.

What does Muse need to call GET /issues with a workspace token?

A workspace token covers every website in the workspace, so each call needs websiteId or domain to name one. Without it Flowsery returns 404 Website not found, not an auth error. Tell Muse to run GET /websites first and carry the ID through.

Where does Muse get a visitor ID for GET /visitors/{visitorId}?

From GET /realtime/map, the only read that returns visitorId. The endpoint takes a _fs_vid value, and no issue payload carries one. A guessed id returns 404, so tell Muse not to invent one.

What happens when Muse hits a Flowsery rate limit?

Flowsery answers with a 429 and adds Retry-After in seconds. Every response also carries RateLimit-Remaining and RateLimit-Reset. Tell Muse to read those headers and pace the sweep instead of retrying blind.

Why is a suspended issue missing from my Muse results?

GET /issues leaves suspended issues out of the default response until you ask for status=suspended. The four statuses are open, in_progress, resolved and suspended. If an issue vanished and you did not expect it, check Muse's Activity log.

What should Muse do when an issue has no sample recording?

sampleRecordingId is nullable, so some issues arrive with nothing to open. Muse should report the issue without a recording rather than substitute a nearby one. You still get its severity and sessionsCount.

Create a workspace token and run a read-only issue sweep, or read the API reference first.

Sources: Meta's Muse connectors help article, How we built safety into Muse, Parallel's Muse custom integrations write-up (14 September 2026), and the Flowsery API reference. Checked 20 September 2026.