Run the Monday Report With a Meta Muse Connector for Analytics Reporting

A weekly report is the one job a Meta Muse connector for analytics reporting can do without ever changing a number, because every endpoint it needs is a GET. Muse writes that connector itself from Flowsery's public API spec. Parallel reported on 14 September 2026 that the work happens on the per-user cloud VM Meta gives each Muse account; Meta's own wording stops at saying that VM has enough compute to do real work. Setup and credentials sit in the Meta Muse connector for web analytics guide; this post starts at the report you run every Monday.

The short version: a weekly report is GET /websites once, GET /overview twice, GET /timeseries for shape, then GET /channels and GET /breakdown to name the cause. Six reads, zero writes, and a websiteId on every one.

Which calls does a weekly report actually need?

A weekly Flowsery report is six calls, and the order matters more than the count. GET /websites hands over the IDs every later call carries. GET /overview runs twice, once per period. GET /timeseries turns the delta into a shape, so a single bad Tuesday stops looking like a trend. Then GET /channels and GET /breakdown name what moved.

GET /countries, /devices, /browsers and /realtime belong to the follow-up question, not the scheduled report. Give the connector the whole list anyway: an endpoint it never calls costs nothing, and one it needs on a Tuesday and lacks costs a rebuilt connector.

How do you ask for a period comparison?

Name both date ranges explicitly and name the timezone. Muse resolves "last week" itself, before the call is made, and Meta publishes nothing about which clock it uses. Flowsery then buckets startAt and endAt against the website's timezone unless the call names one. Two separate resolutions, both silent, both capable of shifting a report by a day.

Report on flowsery.com for the week of 8 to 14 September and the week of
1 to 7 September, timezone Europe/Berlin.
 
Call GET /websites on the first run only, then carry the saved websiteId
through every call.
Then GET /overview once per period.
If sessions or conversions moved more than 10%, call
GET /breakdown?dimension=channel for both periods and name the channel.
Numbers first. No recommendations. If nothing moved, say so and stop.

"Numbers first, no recommendations" earns its place. An agent asked for analysis produces analysis, and one with twenty-two read endpoints and no access to your roadmap builds it on traffic alone. The Grok bot template for analytics reporting ships the same instruction for the same reason.

Why does every call need a website selector?

A Flowsery workspace token covers every website in the workspace, so the API cannot guess which one you mean. Every call needs websiteId or domain. Leave the selector out and the workspace token has no website to resolve, so the call fails instead of quietly returning one website's numbers.

Where the flow_ws_ token goes and why it never belongs in the chat is in the pillar. What the report has to handle is its scope: one token reaches every website.

Tell the connector to store the website IDs after the first run and reuse them. From week two the report is five calls, and re-running GET /websites is only worth it when you add a site.

What can a reporting connector change?

Nothing. Every endpoint in this post is a GET, which makes a reporting connector the safest thing to hand an agent: no approval to configure, no write to supervise, no undo to plan for.

Meta states plainly that it does not review custom connectors or how they use your information, and that missing review matters less when the connector's entire vocabulary is read.

What does an assembled report get wrong that a dashboard does not?

An agent assembling a report makes three mistakes a dashboard cannot: it writes prose about numbers instead of drawing them.

It rounds, then reasons about the rounded number. "Flat week over week" absorbs a 9% drop. Ask for the raw figures alongside the sentence.

It attributes causes it never queried. GET /breakdown?dimension=channel names the channel that moved. No Flowsery endpoint returns a reason, and the connector has no release log or ticket queue to read one from. The agent will supply a reason anyway unless told not to.

It compares uneven windows. A public holiday, a seven-day window against a six-day one, a timezone shift. A dashboard is wrong in ways you can see; a paragraph is not.

The fix for all three is GET /timeseries with interval=day. Day-level numbers under the weekly total let a reader check the agent's sentence against the shape, which is why the dashboard stays open beside it.

What does a weekly report cost when it runs every week?

Muse meters everything against one weekly token allowance, and the plan figures sit in the pillar. What a scheduled job changes is the shape of the spend, not the rate card: the same reads run 52 times a year whether or not anybody reads the output.

Six reads and a paragraph of prose is a small weekly spend. The version that goes wrong is not: an agent retrying a failing call twenty times, every Monday, forever, because nobody told it the selector was required.

The API is on both Flowsery plans, so the weekly run does not depend on which one you are on.

What breaks on reporting specifically?

Four things, and none of them are authentication, which works on the first call or it does not.

The first is the timezone, the failure that survives longest because the report still arrives and still looks correct. startAt and endAt without a timezone bucket against the website's own timezone, the one set in Flowsery rather than the one the person asking for the report lives in, so "last week" silently covers a different seven days than the one on their calendar.

The second is the missing websiteId, which the agent will try to solve by rewriting the query rather than adding the parameter.

The third is drift in the saved skill. Parallel reported on 14 September 2026 that Muse saves a custom integration as a reusable skill that persists across conversations, which freezes the call list at the moment the connector was built. Meta does not document this, so treat the freeze as observed behaviour rather than a guarantee. When the API changes, the pillar's one-message repair applies unchanged. Nobody is watching when a scheduled report breaks, so re-read the reference on a calendar reminder rather than on a failure.

The fourth is the report nobody reads. One that states the delta, names the channel and stops gets read for years; one that editorialises is ignored by month three.

Frequently Asked Questions

Can a Muse reporting connector change my Flowsery data?

Not if you build it from the reporting endpoints alone. The thirteen a reporting connector actually needs all read: GET /overview, /timeseries, /pages, /referrers, /channels, /campaigns, /countries, /devices, /browsers, /breakdown, /goals, /realtime and /websites. Flowsery's write calls cover goals, payments and issue status; a reporting connector is told about none of them.

Why does the second period come back empty?

The second GET /overview carries a startAt and endAt the connector wrote itself, so check what it actually sent: Flowsery defaults startAt to thirty days ago and endAt to now whenever either is missing, and a window with no traffic in it comes back as zeros rather than an error. Give Muse both ranges as literal dates in the prompt rather than as "the week before", and check that the two responses differ before you read the delta.

Can it compare more than two periods?

Yes. Each period is its own GET /overview or GET /timeseries call with its own startAt and endAt, so four quarters costs four calls. Give every one the same timezone or the comparison spans different day boundaries.

Does the weekly report run when the app is closed?

Meta says Muse keeps working after the app is closed and comes back when something changes or it needs approval. Its Help Centre documents reminders and scheduled tasks as a Muse capability and says nothing about a custom connector running inside one (checked 20 September 2026). Verify an unattended weekly run for a month before you depend on it.

Should I use Muse or the Grok bot template for this?

Pick by where the report has to land. The Grok bot template for analytics reporting installs from a share link with the skill text already written and posts into the chat your team already reads; Muse writes its own connector from the public spec and keeps the output in its own app. Both read the same Flowsery API, and every endpoint either one calls is a GET.

What does the connector call first?

It calls GET /websites, once, on the first run. That returns the website IDs every later call carries. Tell the connector to store them and reuse them, and from week two the report is five calls.

Which token does a Muse reporting connector use?

A flow_ws_ workspace token, pasted into Muse's secure credential prompt and never into the chat. One workspace token spans every website in the account, so the connector can reach all of them. That is why every call still names a websiteId.

What happens when a call has no websiteId?

The call fails. A workspace token has no single website to resolve, so the API does not quietly return one site's numbers. The agent will try to fix it by rewriting the query, so tell it up front that the selector is required.

Do I need a specific Flowsery plan for the weekly report?

No. The API is on both Flowsery plans, so the weekly run does not depend on which one you are on. Muse's own weekly token allowance is a separate limit.

Which timezone does a Flowsery weekly report use?

The one you name in the call. If startAt and endAt arrive without a timezone, Flowsery buckets them against the website's own timezone, which is set in Flowsery and may not be yours. Name the timezone in the prompt, or "last week" can cover a different seven days than your calendar.

Create a workspace token and hand Muse the spec, or read the API reference first.

Sources: Meta's Muse connectors help article, Parallel's Muse custom integrations write-up (14 September 2026), and the Flowsery OpenAPI spec. Checked 20 September 2026.