Very little of the time spent on a payments integration goes into the payment code itself. Most of it goes into the loop around it.

You write a webhook handler, and now you need an event to test it with. So you expose your laptop to the internet with a tunnelling tool, paste the temporary URL into the dashboard, copy the signing secret into your environment, make a test payment, and switch back to your terminal to see whether anything arrived. If the handler fails, you fix it and go round again, often with a new tunnel URL to register. Somewhere in between, you open the dashboard to check a customer's details, then the API reference to remember what a field is called.

Today we are releasing the Bachs CLI to shorten that loop. It is one command, bachs, for the work that surrounds your integration: receiving webhooks on your own machine, sending yourself test events, checking and redelivering past events, and calling any Bachs API operation without leaving your terminal. It is built for the developers who write Bachs integrations, whether that is a checkout for one product, a subscription business or a marketplace with many sellers.

Webhooks on your own machine

The part of the loop that costs the most is getting an event to your laptop. Bachs delivers a webhook by sending a request to an address on the internet, and your laptop does not have one. It sits behind a router that does not accept requests from outside, which is why developers reach for tunnels in the first place. With the CLI it is one command:

$ bachs listen --forward-to localhost:3000/webhooksReady! Forwarding sandbox events to http://localhost:3000/webhooksYour webhook signing secret is whsec_a1b2c3...

Your machine opens the connection to Bachs, so nothing has to reach in. There is no public URL to register, no inbound port and no firewall change, and it works on office networks and behind a home router. The events that arrive are real and signed, with a signing secret that belongs to this session only. The verification code you test against it is the code you will run in production; only the secret changes.

If you only care about a few events, name them with --events. When you press Ctrl-C, the session closes and your account is exactly as it was. Your registered webhook destinations are never touched.

An event when you need one

Sometimes you do not want to make a payment just to see what your handler does with it. bachs trigger collection.succeeded sends a sample event through the normal delivery path, signed like any other, so it reaches your listening session the way a real one would.

It only works in the sandbox, on purpose. A fake "payment succeeded" event in production could lead a system to deliver an order nobody paid for, so the CLI refuses instead of warning. In production, the way to see an event again is to replay a real one.

See what happened, and send it again

When a delivery goes wrong, the first question is what Bachs actually sent. bachs events list shows your recent events and how each delivery went. bachs events replay sends one of them again. After an outage on your side, bachs events replay-failed redelivers everything that failed, and running it with --dry-run first shows you exactly what it will resend before it sends anything.

The whole API, one command away

Every Bachs resource is a command group. Type a resource on its own and the CLI lists what you can do with it:

$ bachs customersUsage: bachs customers <operation> [flags]Operations: create Create a customer get <customer_id> Retrieve a customer list List customers update <customer_id> Update a customer

Customers, payments, subscriptions, payouts, refunds, products, transfers and the rest work the same way. You can look up the customer behind a failed webhook, check a payment's status or create a test product without opening the dashboard. Each command runs with your key's permissions, so what you can do from the terminal is what your key can do anywhere else.

Know where you are before you change anything

A terminal does not show which account it is pointed at, so the CLI tells you when you ask. bachs whoami shows the environment, the API address and the start of the key in use, with the rest of the key hidden:

$ bachs whoamiEnvironment: sandboxAPI base: https://sandbox-api.bachs.ioKey: sk_sandbox_a1b2c3d4…

To connect a machine, bachs login opens your browser and asks you to approve a short code in the dashboard. Use bachs login --sandbox to connect to the sandbox instead of production. The key it creates can read your data and run local testing, but it cannot move money, and it expires after 30 days. It is separate from the keys your servers use, so you can revoke it in the developer portal without touching anything in production. If you pass a key yourself, its prefix decides the environment: sk_sandbox_ for the sandbox and sk_live_ for production.

What is next

The CLI is at version 0.2.5. Shell completions are in progress. Next on the list are output formats for scripts, list commands that walk through every page for you, and named profiles for people who work across more than one Bachs account. The roadmap lists what is planned and, just as usefully, what is not.

Get started

Install the CLI with npm, then connect it to the sandbox:

npm install -g @bachs/clibachs login --sandbox

Homebrew and Scoop packages are also available. The CLI documentation covers every command, and Test webhooks locally walks through your first forwarding session.

Then open your terminal next to your editor, start bachs listen, and keep building.