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 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
- The public service currently has no supported browser-to-CLI seller session exchange. Website sign-in therefore does not unlock seller API calls from this CLI. The `buy` web checkout route does not issue Link spend requests; it expects a token from an authorized integration.
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 API | Signed-in user credential and seller access |
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
- # Without a signed-in integration, returns browser sign-in and seller links.
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, and no developer or infrastructure key can replace user authorization. Never pass credentials in arguments, log them, or extract them from browser storage. Seller integrations use `tixbit sell create --confirm < listing.json`.
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. Optional fields include `row`, `seatNumbers`, `faceValueCents`, `assetPaths`, `disclosures`, and `notes`; the server validates them and enforces seller access. Creation requires both `--confirm` and `termsAccepted: true`. Submission is not a claim that the listing is live. After uncertain creation, inspect `sell list` before retrying.
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