> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bachs.io/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Money is always a decimal string at the currency's precision (for example "29.00"), paired with an ISO 4217 currency field. Never use minor units.
> Build against the sandbox first: base URL https://sandbox-api.bachs.io with sk_sandbox_ keys. Production is https://api.bachs.io with sk_live_ keys; going live is a key swap.
> Treat webhooks (for example collection.succeeded) as the source of truth for fulfilment, never client-side events or redirects.
> Subscriptions are created by completing a checkout for a recurring product. There is no direct create-subscription endpoint.
> IDs carry resource prefixes (cust_, prod_, sub_, chk_, inv_, ref_) and timestamps are ISO 8601 UTC.
# Bachs CLI
> Drive your Bachs integration from the terminal. Pair your machine through the browser, forward live events to localhost, and call every API operation as a command.
The Bachs CLI is a single binary that talks to the same API your server does. It pairs with your account through the browser, forwards live webhook events to a port on your machine, and exposes every API operation as a command, so you can inspect and change your integration without writing a request by hand.
It is one static binary with no runtime to install first, whatever language your application is written in.
***
## Install
```bash macOS and Linux theme={"dark"}
brew tap bachsdev/bachs
brew install bachs
```
```bash Node projects theme={"dark"}
npm install -g @bachs/cli
```
```powershell Windows theme={"dark"}
scoop bucket add bachs https://github.com/bachsdev/scoop-bachs
scoop install bachs
```
You can also download a build for your platform from [the releases page](https://github.com/bachsdev/bachs-cli/releases). Debian and RPM packages are published there too.
Check what you have:
```bash Confirm the install theme={"dark"}
bachs --version
```
***
## Log in
`bachs login` prints a short code, opens your browser, and waits. Approve the request in the dashboard and the CLI receives its credentials.
```bash Connect this machine theme={"dark"}
bachs login
```
```text Response theme={"dark"}
Your pairing code is ABCD-EFGH
Approve it at https://app.bachs.io/cli-login?code=ABCD-EFGH
Opened in your browser.
Waiting for approval… ....
✓ Logged in. Credentials saved to /Users/you/.config/bachs/config.json
This key can read your data and run local testing. It cannot move money, and it expires in 30 days.
```
Check that the code on the approval screen matches the one in your terminal before approving. That match is what ties the request to *this* machine.
Pairing writes a key to `~/.config/bachs/config.json` with owner-only permissions. It is separate from the keys you create by hand, so you can revoke it from the [developer portal](https://app.bachs.io/developer/portal) without touching your server's credentials.
Add `--sandbox` to pair against the sandbox rather than production:
```bash Pair against sandbox theme={"dark"}
bachs login --sandbox
```
**In CI, or on a machine with no browser**, set `BACHS_API_KEY` in the environment instead. Avoid `bachs login --api-key`: a key passed on the command line is written to your shell history and is readable by other local users through the process list.
***
## What you can do
Receive live webhook events on your own machine while you build. No public URL and no tunnel.
Exercise your handler without making a real payment. Sandbox only.
List recent events with how their delivery went, and redeliver the ones that failed.
Every endpoint in the API is a command, from `bachs customers list` to `bachs payouts get`.
***
## Environments
Your stored credentials decide which environment the CLI talks to. `bachs login` pairs against production by default, and `bachs login --sandbox` pairs against the sandbox.
```bash Check which one you are on theme={"dark"}
bachs whoami
```
```text Response theme={"dark"}
Environment: sandbox
API base: https://sandbox-api.bachs.io
Key: sk_sandbox_a1b2c3d4…
```
When you pass a key yourself, the prefix selects the environment: `sk_sandbox_` targets the sandbox and `sk_live_` targets production. There is no separate flag to keep in step with the key you are using.
Build against the sandbox first. Going live is a key swap, not a code change.
***
## Configuration
Credentials resolve in this order, so a one-off command can target another account without disturbing what you have stored:
| Source | When to use it |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| `--api-key` on the command | A single command against a different account. Avoid for routine use: it lands in your shell history. |
| `BACHS_API_KEY` environment variable | CI, containers, and anywhere you would rather not write a key to disk. |
| `~/.config/bachs/config.json` | The default. Written by `bachs login` with owner-only permissions. |
Two environment variables change where things go:
* `BACHS_API_KEY` supplies credentials without a config file.
* `BACHS_CONFIG_DIR` moves the config file somewhere other than `~/.config/bachs`.
***
## Next steps
* [Command reference](/cli/commands) for every command, flag, and argument.
* [Test webhooks locally](/developer-portal/local-testing) to forward live events to your machine and verify a real signature.
* [Coming soon](/cli/roadmap) for what we are building next.