drafty
Stripe CLI logo

Build a Stripe payments & events dashboard with Claude

Connect the Stripe CLI to Claude, ask for a payments and events dashboard from your live numbers, and publish it to a link your team comments on directly — no BI tool, no screenshots pasted into Slack.

What you'll build
A self-contained payments dashboard — gross volume, payment success rate, recent charges, disputes, and a live stream of recent events — generated by Claude from your real Stripe data via the CLI, then published to a drafty.im/canvas/… link. Your team clicks the exact chart or number they want changed and leaves a note. Claude reads the comments and ships a revised version to the same URL.

This is an end-to-end example: connect a data source through the Stripe CLI, generate a dashboard from live numbers, and close the review loop on one link. Total time, start to shared link, is under fifteen minutes. The same shape works for any of the other examples — only the connection step changes.

Here's the finished dashboard, published to a canvas — click any tile or number to leave a comment, exactly as your team would:

Live canvas — comment on any elementOpen ↗

The three moving parts

  1. The Stripe CLI gives Claude read access to your Stripe account — balance, charges, payment intents, events, disputes — through commands it runs in your terminal. It authenticates with a restricted key, so you control what it can touch.
  2. Claude runs the CLI, pulls the numbers, and writes a single self-contained HTML dashboard. You iterate on it in the artifact panel until it's right.
  3. Drafty turns that HTML into a stable link your team reviews. Comments pin to the exact element; Claude ships the fix to the same URL.

The generation step is fast now. The part this example is really about is the third one — getting the dashboard in front of people without losing their feedback to a screenshot circled in Preview.

Step 1 — Connect the Stripe CLI

Install the official Stripe CLI, then authenticate. You run this part yourself once.

Install (macOS, Homebrew):

claude
brew install stripe/stripe-cli/stripe

On other platforms, install via npm with npm i -g @stripe/cli, Scoop on Windows, or the stripe/stripe-cli Docker image.

Authenticate:

claude
stripe login

stripe login opens a browser to authorize the CLI and generates a restricted API key for your account — valid for 90 days, stored locally in ~/.config/stripe/config.toml. Once it's logged in, Claude can run stripe get, stripe charges list, stripe events list, and the other read commands in your terminal.

Safety first
For an unattended agent, create a restricted API key in the Stripe Dashboard scoped to read access only on the resources you need (charges, payment intents, events, disputes) and pass it with stripe --api-key rk_live_… get …. A reporting dashboard only reads — it has no reason to hold write permissions. Never paste a full secret key into a config file or commit any key to a repo.

Step 2 — Pull the numbers

Ask Claude in plain language. It runs the CLI's read commands (stripe get, stripe charges list, stripe events list) to fetch real data:

claude
Using the Stripe CLI, pull everything we need for a payments and events dashboard: gross volume this month vs. last month, payment success rate over the last 30 days (succeeded vs. failed charges), count of open disputes, the 10 most recent charges with status and amount, and the last 15 events from the event log with their type. Summarize the figures before you build anything.

Claude runs the commands, returns the figures, and you sanity-check them against the Stripe Dashboard before going further. This is the moment to catch a wrong assumption — a test-mode key, a currency mix, a status filter you didn't expect — while it's cheap.

Step 3 — Build the dashboard

Once the numbers look right, ask for the artifact:

claude
Build a single self-contained HTML dashboard from those figures. Gross volume as the hero number with month-over-month change, then tiles for payment success rate, failed payments, and open disputes. A recent-charges table and a recent-events stream at the bottom. Clean, no external dependencies — inline the CSS and any chart code.

Claude renders it live in the artifact panel. Iterate in place — you're not regenerating from scratch:

Step 4 — Publish to Drafty for review

A Claude artifact link is a preview, not a stable URL — iterate the artifact and the link you already sent now shows the old version. Ask Claude to publish it to a Drafty canvas instead, so the link you share always stays current:

claude
Publish this dashboard to Drafty as a canvas and give me the shareable link.

Claude pushes the dashboard and hands back a drafty.im/canvas/… link that renders on any device. Send it — your team opens it in a browser, no login and no Claude account needed.

Step 5 — The review loop

This is the part that's not obvious until you've done it once.

A reviewer clicks the specific tile, chart, or number they want changed and leaves a pinned comment — "this success rate looks low, are we counting test-mode charges?" The comment is anchored to that element, not floating in a Slack thread. Claude reads the comments through the CLI, reruns the relevant Stripe command if needed, and pushes a revised dashboard to the same URL. The reviewer refreshes and sees the change; the thread stays attached to the element.

The mechanic matters because of what it removes. A Slack message about a chart produces "the number on the left looks wrong." A pinned comment on the actual tile produces "this — exclude test-mode charges from the success rate." One of those produces a correct revision; the other produces a guess.

Keeping it fresh

A CLI-generated dashboard is a snapshot — it holds the numbers Claude pulled when it built it; it doesn't re-run the Stripe commands when someone opens the link. For a weekly review or a board-ready snapshot, that's fine.

To make it a live canvas that always shows today's figures, copy this prompt — Claude sets up the refresh for you and schedules it to run on its own:

claude
Turn this Stripe dashboard into a live canvas: every morning, re-run the Stripe CLI commands to pull the latest payments and events, rebuild the dashboard, and push a new version to the same canvas URL so the link always shows today's figures. Schedule it to run daily on its own.

The link stays stable while the content updates underneath it — see keeping a canvas updated automatically.

What to watch for

Stripe CLI dashboard with Claude — FAQ

Do I need to paste my Stripe secret key anywhere?
No. Running stripe login authorizes the CLI through a browser and generates a restricted API key with read access, stored locally at ~/.config/stripe/config.toml. For an unattended agent, create a restricted key scoped to read-only on the resources you need and pass it with --api-key — never a full secret key, and never committed to a repo.
Is the dashboard live or a snapshot?
A snapshot. It contains the numbers Claude pulled when it built the file; it does not re-run the Stripe commands when someone opens the link. To refresh it, ask Claude to repull and re-push to the same URL — or put that on a daily schedule so the stable link always shows current numbers.
Can my team comment without a Stripe or Claude account?
Yes. The dashboard is published to a Drafty canvas link that renders in any browser. Reviewers click the exact element they want changed and leave a pinned comment with no login required. Only the person connecting Stripe needs access to the account.
Is it safe to give Claude access to my Stripe account?
Use the restricted key stripe login generates, or a read-scoped restricted key you create yourself — a payments dashboard never needs more than read access. Every command runs in your terminal where you can see exactly what it touched. Don't grant write scopes for a read-only reporting task.
How is this different from Stripe Sigma or a BI dashboard?
Sigma and BI tools query live data against a model you maintain — the right choice for governed reporting at scale. This approach is for a fast, shareable snapshot you can spin up in minutes and iterate by talking to Claude, then collect feedback on inline. Different jobs: one is a standing system, the other is a quick reviewable deliverable.