Debugging a Stripe integration locally usually means guessing what the SDK actually sends, sprinkling log statements, or opening the Stripe Dashboard after the fact. stripeek shows you the full request/response pair as it happens — headers, body, status, and latency — without touching your application code. Stripe responses are deeply nested JSON, and stripeek lets you navigate and filter that structure interactively, which is far faster than squinting at raw logs.

stripeek runs as a reverse proxy between your application and api.stripe.com. Point your Stripe SDK at http://localhost:4242 and every request/response pair appears in a browsable TUI — with full JSON inspection, request grouping, persistent history, and clickable Stripe Dashboard links.

For local development only.
Redirecting your SDK's base URL to stripeek means your app routes all Stripe traffic through the proxy. If stripeek isn't running, every Stripe API call will fail. Never commit these changes or deploy them to staging or production — keep them in local dev overrides (environment-specific initializers, .env.development, or a dev-only boot file).

With request groups and filtering:

Installation

go install github.com/progapandist/stripeek/cmd/stripeek@latest

Requires Go 1.24 or later. The binary lands in $(go env GOPATH)/bin — make sure that's on your $PATH. You can also download the binaries for different platforms from the release page. Easier distributions like a Homebrew formula will be added at the later stage when the feature set somewhat stabilizes.

Active development. The tool is under the active development and new features/improvements land often on main before being included in a tagged release, prefer go install github.com/progapandist/stripeek/cmd/stripeek@main to install directly from the main branch.

Quick start

stripeek          # listens on http://localhost:4242

Then redirect your Stripe SDK to the proxy — in your local dev environment only. Stripe calls will fail if stripeek isn't running after this change, so guard it behind an environment check:

Ruby

# config/initializers/stripe.rb (or equivalent dev-only file)
if Rails.env.development?
  Stripe.api_base = "http://localhost:4242"
end

Python

import os
if os.getenv("APP_ENV") == "development":
    stripe.api_base = "http://localhost:4242"

Node.js

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY, {
  ...(process.env.NODE_ENV === "development" && {
    host: "localhost",
    port: 4242,
    protocol: "http",
  }),
});

Go

if os.Getenv("APP_ENV") == "development" {
    stripe.SetAPIBase("http://localhost:4242")
}

stripeek proxies every request to the real Stripe API and captures the full request/response pair, including headers, body, status code, latency, and Stripe request ID. Your keys are redacted from captured headers automatically.

App setup example (Rails, but the similar approach will apply for other frameworks)

config/initializers/stripe.rb:

Stripe.api_key = ENV.fetch("STRIPE_SECRET_KEY")

# Route traffic through stripeek when developing locally.
# Requires `stripeek` to be running — Stripe calls will fail without it.
if Rails.env.development? && ENV.key?("STRIPE_PROXY_URL")
  Stripe.api_base = ENV.fetch("STRIPE_PROXY_URL")
end

Start your server with the variable set to enable proxying:

STRIPE_PROXY_URL=http://localhost:4242 bin/rails server

Omit the variable (or start the server normally) to talk to Stripe directly. Production and staging are never affected — the block only runs in the development environment.

Keyboard shortcuts

Calls pane

Inspector pane

Groups

Groups allow you to visually cluster the requests which can be useful when you want to quickly grock all the traffic related to testing a certain feature (e.g., all the requests you make to Stripe when your app's admin interface loads the subscription view). To group the upcoming requests automatically hit ctrl+g and the new group will be created and assigned a random name based on color of the markers that will visually separate the requests in the TUI.

The inspector header shows a TEST / LIVE badge for each call, inferred from the API key prefix (the key itself is never stored).

Stripe object IDs in the inspector are rendered as clickable hyperlinks to the Stripe Dashboard (requires a terminal with OSC 8 support — iTerm2, WezTerm, Kitty). Links follow the call's mode, so a live request opens the live dashboard instead of the test one.

Configuration

Contributing

git clone https://github.com/progapandist/stripeek
cd stripeek
make build     # compile
make check     # fmt + vet + lint + build
go test ./...  # run tests

Release process

Releases are automated via goreleaser and GitHub Actions. Pushing a semver tag to main triggers a build for all platforms and a GitHub release with attached archives and checksums.

Versioning: this project uses Semantic Versioning. While the major version is 0, minor bumps (v0.2.0, v0.3.0) signal new features and patch bumps (v0.1.1) signal bug fixes. There are no compatibility guarantees before v1.0.0.

To cut a release:

# make sure you're on main and the working tree is clean
git checkout main
git pull

# create and push the tag — this is the only step required
git tag v0.2.0
git push origin v0.2.0

GitHub Actions runs goreleaser, which:

1. Compiles binaries for Linux (amd64, arm64), macOS (amd64, arm64), and Windows (amd64)
2. Creates a GitHub release with tar.gz/zip archives and checksums.txt

You can validate the goreleaser config locally without building:

make release-check

You can do a full local snapshot build (all platforms, no publishing) with:

make snapshot   # outputs to ./dist/