@paybox-sh/sdk 0.7.0 → 0.8.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +27 -15
- package/SKILL.md +121 -0
- package/dist/{chunk-EBB4HNOB.js → chunk-OBZSVPP7.js} +339 -130
- package/dist/chunk-OBZSVPP7.js.map +1 -0
- package/dist/cli.js +65 -51
- package/dist/cli.js.map +1 -1
- package/dist/index.d.ts +140 -52
- package/dist/index.js +1 -1
- package/package.json +12 -4
- package/dist/chunk-EBB4HNOB.js.map +0 -1
package/README.md
CHANGED
|
@@ -1,12 +1,13 @@
|
|
|
1
1
|
# @paybox-sh/sdk
|
|
2
2
|
|
|
3
|
-
Typed Node SDK and `paybox` CLI for the
|
|
3
|
+
Typed Node SDK and `paybox` CLI for the PayBox agent API. It mirrors the MCP tool
|
|
4
4
|
surface — `list_credentials`, `request_payment`, `claim_payment_credentials`,
|
|
5
5
|
`request_wallet_sign`, `request_secret`, `request_swap`, `discover_services`,
|
|
6
6
|
`pay_x402`, `use_service`, `get_portfolio`, `get_buy_link`,
|
|
7
|
-
`request_account_change`, `get_request`, and
|
|
7
|
+
`request_account_change`, `get_request`, and read-only plugin tools (`world_*`,
|
|
8
8
|
`hyperliquid_*`) — but talks to the REST API directly, with no MCP host and no
|
|
9
9
|
signing iframe.
|
|
10
|
+
Geofenced World money tools are MCP-only.
|
|
10
11
|
|
|
11
12
|
Wallet signing is **non-custodial and runs in-process**: the SDK reuses the exact
|
|
12
13
|
signing core from the wallet-sign iframe (`@paybox/mcp-app`), builds the chain
|
|
@@ -20,18 +21,26 @@ pnpm add @paybox-sh/sdk # library
|
|
|
20
21
|
npx @paybox-sh/sdk login # or use the CLI directly
|
|
21
22
|
```
|
|
22
23
|
|
|
24
|
+
Driving this CLI from an agent? [`SKILL.md`](SKILL.md) ships in the package and
|
|
25
|
+
describes the install and login flow as an agent skill: what the human has to do
|
|
26
|
+
(approve wallets, paste one signing key), and what the agent should not do
|
|
27
|
+
around it.
|
|
28
|
+
|
|
23
29
|
## CLI
|
|
24
30
|
|
|
25
31
|
```bash
|
|
26
32
|
# Authenticate: OAuth in the browser (approve with a passkey), or store a key.
|
|
27
33
|
# `paybox login` is a guided two-step: OAuth, then it opens the app to provision
|
|
28
34
|
# a wallet signing key and prompts you to paste the `pbxk1.` token back.
|
|
29
|
-
|
|
35
|
+
# The OAuth step is a device-code grant, so the browser that approves does not
|
|
36
|
+
# have to be on the machine running the CLI.
|
|
37
|
+
paybox login # device-code OAuth, then provision a key
|
|
30
38
|
paybox login --no-provision # OAuth only, skip the key step
|
|
31
39
|
paybox login --key pbx_live_… # personal API key instead (no OAuth)
|
|
32
|
-
paybox login
|
|
40
|
+
PAYBOX_SIGNING_KEY=pbxk1.… paybox login # supply the signing key non-interactively
|
|
33
41
|
|
|
34
42
|
paybox credentials # list usable credentials
|
|
43
|
+
# `--credential <id>` below is the `credential.id` from that list, not the wallet name.
|
|
35
44
|
paybox pay --credential <id> --merchant Acme --url https://acme.com --amount 1999
|
|
36
45
|
paybox secret --credential <id> --purpose "deploy" # one-time token
|
|
37
46
|
paybox secret --credential <id> --raw # raw value (grant-gated)
|
|
@@ -44,13 +53,13 @@ paybox discover --raw "weather api" # debug: uncurated compact summaries
|
|
|
44
53
|
paybox pay-x402 --credential <id> --url https://svc/api --accepts @accepts.json
|
|
45
54
|
paybox use-service --credential <id> --url https://svc/api # paybox pays + fetches
|
|
46
55
|
paybox claim <request_id> # claim an approved payment's card (one-time)
|
|
47
|
-
paybox buy-link --credential <id> --amount-usd 50 #
|
|
56
|
+
paybox buy-link --credential <id> --amount-usd 50 # defaults EVM funding to Base
|
|
57
|
+
paybox buy-link --credential <id> --destination eip155:1 --currency eth
|
|
48
58
|
paybox account-change --note "need a wallet grant" # manage_url for the user to open
|
|
49
59
|
paybox request <request_id> --wait # poll a pending request
|
|
50
60
|
|
|
51
61
|
# Plugins (enable them in the paybox app first)
|
|
52
62
|
paybox world markets --status active # browse prediction markets
|
|
53
|
-
paybox world buy --credential <id> --mint <outcome-mint> --size 10 --wait
|
|
54
63
|
paybox hyperliquid markets # spot discovery
|
|
55
64
|
|
|
56
65
|
paybox version # installed version (+ update check)
|
|
@@ -66,13 +75,8 @@ clears `~/.config/paybox` and prints the `npm rm -g` line (a package can't remov
|
|
|
66
75
|
its own binary). For project installs use `pnpm up`/`pnpm rm`, or `npx
|
|
67
76
|
@paybox-sh/sdk@latest` to always run the latest without installing.
|
|
68
77
|
|
|
69
|
-
`sign`, `swap`, `pay-x402`, `use-service
|
|
70
|
-
|
|
71
|
-
clears immediately (autonomous grant). When the grant requires approval — World
|
|
72
|
-
trades always do — pass `--wait`: the CLI waits for your passkey approval in the
|
|
73
|
-
app and then signs in-process (there is no signing window on this surface).
|
|
74
|
-
Without `--wait` the command returns `pending_approval`; approve in the app,
|
|
75
|
-
then re-run or poll `paybox request <id>`.
|
|
78
|
+
`sign`, `swap`, `pay-x402`, and `use-service` can complete in-process with a
|
|
79
|
+
configured `pbxk1.` key. World buy/sell/redeem are MCP-only.
|
|
76
80
|
|
|
77
81
|
For a Solana `swap` the SDK re-pins a fresh recent blockhash immediately before
|
|
78
82
|
signing (parity with the signing window — the quote-time blockhash expires
|
|
@@ -93,14 +97,18 @@ import { PayboxClient } from "@paybox-sh/sdk";
|
|
|
93
97
|
const paybox = PayboxClient.fromConfig(); // reads ~/.config/paybox + env
|
|
94
98
|
// or: new PayboxClient({ apiKey: "pbx_live_…", signingKey: "pbxk1.…" });
|
|
95
99
|
|
|
96
|
-
const
|
|
100
|
+
const { credentials, ungranted } = await paybox.listCredentials();
|
|
97
101
|
const pay = await paybox.requestPayment({
|
|
98
|
-
credentialId:
|
|
102
|
+
credentialId: credentials[0].credential.id,
|
|
99
103
|
merchant: "Acme",
|
|
100
104
|
merchantUrl: "https://acme.com",
|
|
101
105
|
amountCents: 1999,
|
|
102
106
|
});
|
|
103
107
|
|
|
108
|
+
// Ungranted credentials the user owns but hasn't granted this connector — pass
|
|
109
|
+
// an id to request_account_change's `add` to ask for access.
|
|
110
|
+
console.log(ungranted.map((c) => `${c.name} (${c.kind})`));
|
|
111
|
+
|
|
104
112
|
const sig = await paybox.requestWalletSign({
|
|
105
113
|
credentialId: walletId,
|
|
106
114
|
chain: "eip155:8453",
|
|
@@ -134,6 +142,10 @@ env vars on shared Windows machines.
|
|
|
134
142
|
|
|
135
143
|
## Develop
|
|
136
144
|
|
|
145
|
+
`pnpm-lock.yaml` also contains the `../mcp-app` importer because this SDK
|
|
146
|
+
consumes the iframe's signing core through `file:../mcp-app`. The iframe build
|
|
147
|
+
shares this dependency resolution but keeps its installed modules separate.
|
|
148
|
+
|
|
137
149
|
```bash
|
|
138
150
|
pnpm install
|
|
139
151
|
pnpm typecheck
|
package/SKILL.md
ADDED
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: PayBox CLI setup
|
|
3
|
+
description: >-
|
|
4
|
+
Install and log in to the PayBox CLI (@paybox-sh/sdk) so an agent can pay,
|
|
5
|
+
sign, and hold wallet, card, and secret credentials on the user's behalf. Use
|
|
6
|
+
when the user says "install PayBox", "set up PayBox", "instalar PayBox", or
|
|
7
|
+
asks an agent to connect their PayBox wallet.
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# PayBox CLI setup
|
|
11
|
+
|
|
12
|
+
The user asks to install PayBox. Two things need them: they approve wallet
|
|
13
|
+
access with a passkey, and they paste one signing key. Everything else is yours,
|
|
14
|
+
and they should not see it happen.
|
|
15
|
+
|
|
16
|
+
## Install
|
|
17
|
+
|
|
18
|
+
```bash
|
|
19
|
+
npm install -g @paybox-sh/sdk
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
The CLI runs wherever you run it, which is often not the user's own machine.
|
|
23
|
+
That is fine: login uses an OAuth device-code grant, so the browser that
|
|
24
|
+
approves does not have to be the one the CLI can reach.
|
|
25
|
+
|
|
26
|
+
Never delete or overwrite an existing config directory. To isolate a run from
|
|
27
|
+
credentials the user already has, point `PAYBOX_CONFIG_DIR` at a fresh
|
|
28
|
+
directory.
|
|
29
|
+
|
|
30
|
+
## Log in
|
|
31
|
+
|
|
32
|
+
Run this once, in the same turn the user asks:
|
|
33
|
+
|
|
34
|
+
```bash
|
|
35
|
+
paybox login
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
Add `--base-url` and `--app-url` for an environment other than the default.
|
|
39
|
+
|
|
40
|
+
The command drives the whole flow itself. Do not reimplement any of it: it
|
|
41
|
+
registers a client, starts device authorization, prints a verification URL and a
|
|
42
|
+
short user code, tries to open that URL locally, polls until the user approves,
|
|
43
|
+
then opens the signing-key page and prompts for the key.
|
|
44
|
+
|
|
45
|
+
Login writes progress to stderr as plain prose, not JSON. Watch for the
|
|
46
|
+
verification URL and the `Code:` line.
|
|
47
|
+
|
|
48
|
+
### Step 1 — Authorize wallets
|
|
49
|
+
|
|
50
|
+
The moment login prints the verification URL and code, put **one** message in
|
|
51
|
+
front of the user: a markdown link labeled **Authorize wallets** pointing at that
|
|
52
|
+
URL, plus the code.
|
|
53
|
+
|
|
54
|
+
Send that link even though the CLI also tries to open a browser. When the CLI
|
|
55
|
+
is not on the user's machine, that local open is useless or invisible, and your
|
|
56
|
+
message is the only way they reach the page.
|
|
57
|
+
|
|
58
|
+
The user approves in the browser. If the link opens the PayBox mobile app and
|
|
59
|
+
errors instead, have them open it in a browser.
|
|
60
|
+
|
|
61
|
+
Then wait. The poll is the continue signal. Do not ask the user to type `done`,
|
|
62
|
+
confirm, or send a screenshot, and do not end your turn while login is running.
|
|
63
|
+
If the code expires before they approve, run `paybox login` again for a fresh
|
|
64
|
+
one rather than reusing the old link.
|
|
65
|
+
|
|
66
|
+
### Step 2 — Paste the signing key
|
|
67
|
+
|
|
68
|
+
After approval, login opens the signing-key page and prompts for the key.
|
|
69
|
+
Present a **masked input** for the `pbxk1.` value and write what the user gives
|
|
70
|
+
you to that prompt's stdin.
|
|
71
|
+
|
|
72
|
+
Pass it through the prompt, or set `PAYBOX_SIGNING_KEY` before running `login`
|
|
73
|
+
when nothing is attached to stdin. Never pass it as `login --signing-key <value>`
|
|
74
|
+
on the command line: an argument lands in shell history and is visible to anyone
|
|
75
|
+
who can list processes.
|
|
76
|
+
|
|
77
|
+
Do not ask the user to click the signing-key link, it is already open. Do not
|
|
78
|
+
show the key field before that page has opened, and do not open it twice.
|
|
79
|
+
|
|
80
|
+
Wallet signing is non-custodial: the key stays on the user's machine and PayBox
|
|
81
|
+
never holds it. Never print, log, or echo it.
|
|
82
|
+
|
|
83
|
+
### Step 3 — Confirm
|
|
84
|
+
|
|
85
|
+
```bash
|
|
86
|
+
paybox --json whoami
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
`canSign` must be `true`. If it is `false` the key did not save; redo step 2
|
|
90
|
+
rather than continuing, because signing and swaps will fail without it.
|
|
91
|
+
|
|
92
|
+
## What the user sees
|
|
93
|
+
|
|
94
|
+
From the install request until `canSign` is `true`, exactly two messages, in
|
|
95
|
+
this order:
|
|
96
|
+
|
|
97
|
+
1. The **Authorize wallets** link plus the code.
|
|
98
|
+
2. The masked `pbxk1.` field, after the signing-key page has opened.
|
|
99
|
+
|
|
100
|
+
Nothing else. No "Installing…", "Opening…", "Got it", no CLI version, package
|
|
101
|
+
manager, config path, or request id, and no narration of a retry or fallback. If
|
|
102
|
+
something is blocked, switch approaches quietly. If you have nothing they need
|
|
103
|
+
to act on, send nothing.
|
|
104
|
+
|
|
105
|
+
Match the user's language. Default to English unless they write otherwise.
|
|
106
|
+
|
|
107
|
+
Once `canSign` is `true`, show them what they now have: `paybox --json
|
|
108
|
+
credentials` for the granted wallets, then `paybox --json portfolio --address
|
|
109
|
+
<wallet>` for balances. Every `--credential` takes the `credential.id` from that
|
|
110
|
+
list; a wallet's name is not an id and the command will refuse it. Render a
|
|
111
|
+
compact table, never addresses or raw JSON. The CLI cannot create wallets; it
|
|
112
|
+
uses what the user granted during authorization.
|
|
113
|
+
|
|
114
|
+
## A setup that went wrong
|
|
115
|
+
|
|
116
|
+
- The user had to prompt you after approving wallet access.
|
|
117
|
+
- The key field appeared before the signing-key page opened.
|
|
118
|
+
- You asked the user to click the signing-key link, or to type `done`.
|
|
119
|
+
- You opened either page twice.
|
|
120
|
+
- Setup chat contained anything besides those two messages.
|
|
121
|
+
- A token, API key, or `pbxk1.` value reached the transcript.
|