tixbit 0.2.4 → 0.3.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 +75 -5
- package/dist/cli.js +344 -90
- package/dist/index.d.ts +68 -1
- package/dist/index.js +251 -16
- package/package.json +3 -2
- package/skills/tixbit/SKILL.md +4 -0
- package/skills/tixbit-selling/SKILL.md +167 -0
- package/skills/tixbit-selling/agents/openai.yaml +4 -0
- package/skills/tixbit-selling/references/troubleshooting.md +23 -0
- package/skills/tixbit-selling/references/workflows.md +72 -0
package/README.md
CHANGED
|
@@ -8,7 +8,7 @@ No command requires a TixBit developer API key. Public discovery and links need
|
|
|
8
8
|
|
|
9
9
|
Run `tixbit auth` for public browser sign-in and wallet setup links. This command does not create a CLI session. Open the returned TixBit sign-in page, then complete checkout or selling in your browser. Do not copy browser cookies or bearer tokens.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
Seller-capable builds use `tixbit sell login` for browser OAuth with PKCE and explicit seller consent. CLI 0.3.0 or newer includes a public OAuth client and requires an enabled seller connection. Run `sell capabilities` before signing in; if `configured` is false or the endpoint is unavailable, operator setup is still pending. Website sign-in alone does not create a CLI session. The `buy` web checkout route does not issue Link spend requests; it expects a token from an authorized integration.
|
|
12
12
|
|
|
13
13
|
For wallet setup, use [official Link onboarding](https://link.com/agents): install `@stripe/link-cli` and run `link-cli onboard`. This requires your Link account, not a developer API key. A Link spend request is a separate approval for a selected purchase. See [Link agent checkout](#link-agent-checkout).
|
|
14
14
|
|
|
@@ -19,7 +19,7 @@ For wallet setup, use [official Link onboarding](https://link.com/agents): insta
|
|
|
19
19
|
| Browser purchase | Sign in and approve the final payment in the browser |
|
|
20
20
|
| MPP `purchase` | Your mppx wallet, buyer email, confirmation, total cap, recovery UUID |
|
|
21
21
|
| Automatic Link payment | User-approved payment credential from an authorized integration |
|
|
22
|
-
| Seller
|
|
22
|
+
| Seller CLI | Approved OAuth client, explicit seller consent and owned inventory; exact review before confirmation |
|
|
23
23
|
|
|
24
24
|
## Install
|
|
25
25
|
|
|
@@ -135,7 +135,7 @@ tixbit buy <listingId> --quantity 2 --max-price 300.00 --email buyer@example.com
|
|
|
135
135
|
# No payment is sent; review and approve the final total in the browser.
|
|
136
136
|
tixbit buy <listingId> --quantity 2 --max-price 300.00 --email buyer@example.com --confirm
|
|
137
137
|
|
|
138
|
-
#
|
|
138
|
+
# Requires sell login and current inventory permission.
|
|
139
139
|
tixbit sell list
|
|
140
140
|
```
|
|
141
141
|
|
|
@@ -143,7 +143,7 @@ A handoff returns `success: false`, `status: "authorization_required"`, and exit
|
|
|
143
143
|
|
|
144
144
|
### Optional advanced integrations
|
|
145
145
|
|
|
146
|
-
Authorized applications may supply a user-approved Link payment credential or a signed-in seller's Privy access token. Optional `TIXBIT_LINK_TOKEN` and `TIXBIT_ACCESS_TOKEN` injection is for these integrations only, not normal onboarding. Neither is a TixBit API key
|
|
146
|
+
Authorized applications may supply a user-approved Link payment credential or use the legacy SDK seller methods with a signed-in seller's Privy access token. Optional `TIXBIT_LINK_TOKEN` and `TIXBIT_ACCESS_TOKEN` injection is for these integrations only, not normal onboarding. Neither is a TixBit API key. Never pass credentials in arguments, log them, or extract them from browser storage. The seller CLI uses reviewed OAuth flows below and does not consume `TIXBIT_ACCESS_TOKEN`.
|
|
147
147
|
|
|
148
148
|
`--max-price` is the total USD charge ceiling including ticket fees, not a per-ticket price or a bid. Link checkout sends `maxAmountCents` in both POST requests and refuses payment unless the quote advertises `maxAmountCentsSupported: true`. Payment requires a public checkout deployment that advertises and enforces the total cap. The backend rechecks its actual charge before payment. Link currently accepts only 4-12 alphanumeric listing IDs. Native `sl_UUID` listings are not supported by this payment backend; use link-only `checkout` for browser completion instead.
|
|
149
149
|
|
|
@@ -155,7 +155,76 @@ Seller JSON uses the existing web API schema. Example after seller approval:
|
|
|
155
155
|
{"externalEventId":"AbCd12","section":"GA","quantity":2,"generalAdmission":true,"priceCents":10000,"termsAccepted":true}
|
|
156
156
|
```
|
|
157
157
|
|
|
158
|
-
`priceCents` is the seller's per-ticket asking price, unlike the buyer's total cap.
|
|
158
|
+
`priceCents` is the seller's per-ticket asking price, unlike the buyer's total cap. The reviewed CLI accepts `row`, `seatNumbers`, `faceValueCents`, `disclosures`, `notes`, and optional `ownedImportId`; uploading assets is not part of this interface. Creation requires explicit seller terms acceptance and a separate confirmation of the prepared review. Submission is not proof a listing is live.
|
|
159
|
+
|
|
160
|
+
### Sell your own tickets
|
|
161
|
+
|
|
162
|
+
Seller commands require CLI `0.3.0` or newer and an enabled seller connection.
|
|
163
|
+
Install with `npm install -g tixbit@latest`, verify `tixbit --version`, and run
|
|
164
|
+
`sell capabilities` before signing in. If `configured: false` or the endpoint
|
|
165
|
+
is unavailable, operator setup or deployment is still pending; public discovery
|
|
166
|
+
can continue. `configured: true` alone does not prove client approval or user
|
|
167
|
+
eligibility.
|
|
168
|
+
|
|
169
|
+
The CLI includes a public OAuth client, so end users need no developer API key
|
|
170
|
+
or manual client setup once the companion seller service and account bridge
|
|
171
|
+
are enabled and the exact client has been approved in the required allowlists.
|
|
172
|
+
The workflow below applies when those prerequisites are satisfied.
|
|
173
|
+
|
|
174
|
+
```sh
|
|
175
|
+
tixbit sell --help
|
|
176
|
+
tixbit sell capabilities
|
|
177
|
+
tixbit sell login
|
|
178
|
+
# Open signInUrl, sign in, review consent, then paste full callback on stdin:
|
|
179
|
+
tixbit sell login --complete
|
|
180
|
+
tixbit sell auth-status
|
|
181
|
+
tixbit sell list
|
|
182
|
+
|
|
183
|
+
# Resolve the event/section before preparing seller JSON:
|
|
184
|
+
tixbit search "Braves" --city Atlanta --state GA --json
|
|
185
|
+
tixbit seatmap "$EVENT_ID" --json
|
|
186
|
+
tixbit sell create --file listing.json --dry-run
|
|
187
|
+
tixbit sell create --file listing.json --attempt "$ATTEMPT_UUID"
|
|
188
|
+
tixbit sell review "$REVIEW_ID"
|
|
189
|
+
# Only after approval of the exact preview:
|
|
190
|
+
tixbit sell confirm "$REVIEW_ID" --confirm
|
|
191
|
+
tixbit sell status "$SELLER_LISTING_ID"
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
Generate a UUID v4 for each new intent and preserve it as `ATTEMPT_UUID`.
|
|
195
|
+
Preparing creates a review only. `--dry-run` performs local validation without
|
|
196
|
+
login or network requests. Copy `REVIEW_ID` from preparation, then review and
|
|
197
|
+
confirm it. Credentials and private confirmation nonces are saved in private
|
|
198
|
+
files under `~/.config/tixbit/seller`; never print or paste those files into chat.
|
|
199
|
+
The OAuth callback is `https://mcp.tixbit.com/cli/callback`, with resource
|
|
200
|
+
`https://mcp.tixbit.com/api/mcp`. Localhost production redirects are not used.
|
|
201
|
+
|
|
202
|
+
Operators can provision the public CLI client before account infrastructure is
|
|
203
|
+
enabled using the [explicit offline procedure](https://github.com/tixbit/tixbit-monorepo/blob/main/docs/runbooks/mcp-cli-provisioning.md).
|
|
204
|
+
The fixed-profile command uses the existing signing key, creates no access
|
|
205
|
+
grant, and never changes either client allowlist or production settings. Reuse
|
|
206
|
+
an existing approved matching client when available; provisioning is a separate
|
|
207
|
+
operator action from user sign-in and consent.
|
|
208
|
+
|
|
209
|
+
For repricing use `tixbit sell reprice --file reprice.json`, with
|
|
210
|
+
`{"listingId":"OWNED_ID","priceCents":11000}`. To remove an unsold listing,
|
|
211
|
+
use `tixbit sell delist --file delist.json`, with `{"listingId":"OWNED_ID"}`.
|
|
212
|
+
Both support `--dry-run` and `--attempt` and require the same review/confirm
|
|
213
|
+
sequence. `sell cancel REVIEW_ID` abandons an unexecuted review without changing
|
|
214
|
+
inventory. `sell logout` removes local credentials; revoke the server connection
|
|
215
|
+
through TixBit to invalidate its grant.
|
|
216
|
+
|
|
217
|
+
After a lost confirmation response, inspect the same review and inventory.
|
|
218
|
+
Completed retries replay the result; ambiguous attempts require reconciliation.
|
|
219
|
+
Never rotate attempt IDs or create a duplicate listing to bypass uncertainty.
|
|
220
|
+
Quantity/seat edits, relisting, payout setup, payments and fulfillment are not
|
|
221
|
+
supported. Quantity is 1–20 and USD unit price is 100–5,000,000 integer cents;
|
|
222
|
+
marketplace eligibility and sale-state checks still apply.
|
|
223
|
+
|
|
224
|
+
The distributable [seller skill](skills/tixbit-selling/SKILL.md) includes exact
|
|
225
|
+
workflows, installation and troubleshooting. Copy the complete directory into
|
|
226
|
+
your agent's skills directory; the complete skill is included in the seller-capable
|
|
227
|
+
npm package.
|
|
159
228
|
|
|
160
229
|
MPP `purchase` retains the official mppx path but now requires `--confirm`, `--max-price`, and an explicit `--idempotency-key` before wallet loading. Its challenge hook checks the pathUSD atomic amount before any credential is created, rejects unknown assets/recurring intents, and permits only one payment challenge. The cap covers the ticket charge; network fees, if any, are managed separately by the wallet. SDK callers who inject their own `paymentFetch` own its authorization policy: use `assertMppChallenge` in `onChallenge` as shown below and get user approval before calling `purchaseTickets`. Do not register credential-producing event handlers that bypass this hook.
|
|
161
230
|
|
|
@@ -420,6 +489,7 @@ Returns the full URL to the event page on `www.tixbit.com`.
|
|
|
420
489
|
| `TIXBIT_EMAIL` | Optional alternative to `buy --email` | none |
|
|
421
490
|
| `TIXBIT_LINK_TOKEN` | Optional advanced integration: user-approved Link credential; never an argument | none |
|
|
422
491
|
| `TIXBIT_ACCESS_TOKEN` | Optional advanced integration: signed-in seller user credential, not an API key | none |
|
|
492
|
+
| `TIXBIT_SELLER_CLIENT_ID` | Optional override for the built-in issued public OAuth client ID; not a secret | built-in CLI client |
|
|
423
493
|
| `TIXBIT_PAYMENT_URL` | Canonical MPP endpoint or loopback QA URL; no credentials, query, fragment, or redirects | `https://mcp.tixbit.com/api/purchase` |
|
|
424
494
|
| `MPPX_PRIVATE_KEY` | Optional mppx account source; prefer the OS keychain | mppx keychain |
|
|
425
495
|
|