Is a Metabase public link safe to send outside the company?

It is safe from guessing — the URL contains a long random token — and unsafe from forwarding. Anyone who receives the link can open the dashboard with no login, forever, until an admin disables that specific link or turns public sharing off globally. Treat it as publishing, not as sharing, and never enable it on a dashboard whose filters can be edited in the URL to widen the result set.

What is the difference between public links and static embedding?

A public link is a standalone URL Metabase serves. Static embedding is an iframe whose src carries a JWT you sign server-side, so your application decides who sees it and can lock filter values per viewer. Embedding is the right answer for a customer-facing product; it is heavy machinery for sending one dashboard to a colleague.

Can I email a Metabase dashboard on a schedule?

Yes — dashboard subscriptions send the dashboard to email or Slack on a cron, with results attached as CSV or XLSX if you want the raw rows. The limitation is the format: the recipient gets a flat message, so any discussion happens as email replies that are detached from the number being discussed.

How do I share Metabase results with someone who has no account?

Render the questions you care about into one self-contained HTML page and publish that page to a stable URL with an anchored comment layer. The reader sees the numbers and can ask about a specific cell without a Metabase seat and without a permanently open public link.

How do I keep the same URL every week?

Publish once, keep the report id, and PATCH it on each run. Every run appends a revision at the same URL, so the link stays valid and two weeks can be compared side by side.

How to share a Metabase dashboard

Metabase is unusually good at this compared to most BI tools — there are three real sharing mechanisms and they all work. The question is which one matches what you are actually trying to do, because they are built for different jobs and it is easy to reach for the wrong one.

The three built-in options

Public links. An admin enables public sharing, you click share, and Metabase gives you a URL with a long random token. Anyone who opens it sees the dashboard, with no login, indefinitely. This is genuinely convenient and genuinely a publishing action: the link cannot be un-forwarded, only revoked. Two failure modes worth naming — a public dashboard whose filters are editable in the query string can sometimes be widened by the reader beyond what you intended, and revocation is per-link, so an admin cleanup six months later is a manual audit of every link anyone ever created.

Static embedding. You sign a JWT server-side with your embedding secret, put it in the iframe src, and Metabase renders the dashboard with whatever filter values you locked into the token. This is the correct architecture for showing customers their own data inside your product. It is also an application to build and operate, which makes it wildly disproportionate if the goal is "send the weekly numbers to the leadership channel."

Dashboard subscriptions. A cron that emails or Slacks the dashboard, with optional CSV/XLSX attachments. Good for the standing weekly. The cost is that email is a terminal format: the reply-all thread discussing the churn number lives in a mailbox, not next to the churn number, and nobody who joins in March can find the January explanation.

The gap all three leave

None of them produce something a group can annotate. The number gets discussed somewhere else — Slack, email, a meeting — and the reasoning evaporates. Six weeks later someone asks why Q2 signups dipped and the answer exists only in the memory of whoever was on the call.

The pattern that closes it: render the questions into one self-contained HTML page, publish it to a stable URL, and put an anchored comment layer on it.

Rendering the page

Metabase's API returns a card's results as JSON or CSV without going near the UI:

curl -fsS -X POST "$METABASE_URL/api/card/$CARD_ID/query/json" \
  -H "x-api-key: $METABASE_API_KEY" > card.json

Loop over the card ids on the dashboard, turn each result into an HTML table or a chart, and write one file. Keep it self-contained — inline the CSS, and either inline the charting library or emit plain tables. A page that fetches nothing at view time is a page that renders identically for everyone, forever.

Then publish it, and keep publishing to the same id:

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html digest.html \
        --arg title "Growth — week of $(date +%F)" '{title: $title, html: $html}')"

If you would rather not run the cron, a routine does the same thing on a schedule you set in the UI.

What changes

The weekly numbers land at one URL that never rotates. A reader highlights the retention cell and pins a thread: "cohort definition changed on the 14th, this is not a real drop." That thread survives every subsequent revision. When the same shape appears in October, the explanation is already attached.

Access is a setting on the report — private, team, domain-gated or link — so a board member reads the numbers without a Metabase account and without a public link that outlives the conversation.

When to use Metabase's own sharing instead

Use static embedding when the dashboard is part of a product you ship. Use a public link when the data genuinely is public — a status page, a community metrics board. Use subscriptions when the recipient will read the number and never respond. The digest pattern is for the case in between, which is most internal reporting: a specific audience, a durable record, and a conversation that has to stay attached to the figure it is about.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Create your first report →

Share a Superset dashboard
Comma vs Mode — the same question for a BI notebook
Weekly analytics digest