# Jate CLI — `@jate/cli`

Outils de développement : vérifier sa clé, créer un encaissement de test, et
relayer les webhooks vers votre machine sans rien déployer.

```bash
npx @jate/cli init          # ou installez : npm install -D @jate/cli
```

La configuration se lit dans cet ordre : **arguments** → variables
d'environnement (`JATE_API_BASE`, `JATE_SECRET_KEY`, `JATE_WEBHOOK_SECRET`) →
`.jate.json` à la racine du projet (créé par `init`, en lecture seule par vous).

## `jate init [--base <url>] [--key <clé>]`

Écrit `.jate.json`, vérifie la clé (`GET /v1/me`), affiche le mode
(live ou bac à sable) et les commandes pour continuer.

`.jate.json` porte une clé **live** : `init` l'écrit en `0600` et ajoute la
ligne à votre `.gitignore` si vous êtes dans un dépôt. Passer par
`JATE_SECRET_KEY` reste préférable partout ailleurs que sur votre poste — et
notez qu'une clé passée en `--key` reste dans l'historique du shell.

## `jate me [--json]`

« Ma clé marche-t-elle, et sur quoi ? » — application, business, commission,
portées, webhook configuré ou non, et le mode. **Le mode s'affiche en toutes
lettres** : croire encaisser en direct alors qu'on parle au bac à sable
d'Orange est l'erreur la plus coûteuse d'une intégration de paiement.

## `jate checkouts`

```bash
# Créer une demande de paiement (l'URL s'affiche, --open l'ouvre chez le client)
jate checkouts create --amount 15000 --description "Test" --reference test_1 --open

# Relire un encaissement — la vérité avant de livrer
jate checkouts get jn71…

# La liste, filtrée et paginée
jate checkouts list --status paid --limit 50
```

`create` respecte l'idempotence par `reference` : renvoyez la même commande,
vous récupérez la même demande (affiché « reprise »).

## `jate listen [--port 8787] [--forward-to http://localhost:3000/jate-webhook]`

Le relais de webhooks local, façon `stripe listen`. Il reçoit les notifications
de Jate, **vérifie la signature** (`JATE_WEBHOOK_SECRET`) et affiche chaque
événement.

Le secret est **obligatoire** : sans lui, un corps ne peut pas être vérifié, et
un corps non vérifié ne se traite pas. Le relais refuse alors de démarrer plutôt
que de rejeter chaque événement en 401 sans dire pourquoi.

En mode `--tunnel`, le jeton du relais voyage en en-tête `Authorization`, jamais
dans l'URL. Et **seuls les encaissements en mode test** sont recopiés vers un
tunnel : le miroir aboutit sur une machine de développement, où les montants et
références de paiements réels n'ont rien à faire. Développez avec une clé de
test — avec une clé live, le tunnel reste muet et vous le dit au démarrage.

```
✓ checkout.paid  jn71…  cmd_142  15 000 FCFA
```

Avec `--forward-to`, l'événement vérifié est renvoyé vers votre application en
cours de développement, en-têtes `Jate-Signature` et `Jate-Event-Id` préservés.

Pour que Jate atteigne votre machine, déclarez dans le tableau de bord une
adresse HTTPS publique qui pointe vers le relais — le plus simple, sans compte :

```bash
npx cloudflared tunnel --url http://localhost:8787
```

## Codes de sortie

`0` succès, `1` erreur. Les erreurs d'API affichent leur `code` stable et le
message en français ; les 429 et 503 indiquent le `Retry-After`.