Take your first real deal
Everything outside the sales folder a real deal depends on, the seller's Stripe account behind the proof and the pay link, the mandate, the sending mailbox, the calling number, the calendar, the contract, the door, live keys, payouts and firms, each with the contract a real one meets.
sales's wordsdeal is a jobaccount is a subjectgig is a taskcloser is a memberseller is a clientseller is a buyer
The sales folder runs whole on localhost because every outside system it reads is a sandbox at example.test. A real deal needs a real one behind each. Most are the seller's own, connected once in the customer portal. These are all of them, as the folder reads them:
npx services.dev check --connections # every outside system the sales folder reads, and what stands in for it on localhostservices/deal.ts:49 outcome.proof payment the seller's Stripe account https://stripe.example.test/sellers/{seller}
services/deal.ts:31 roles.closer.talk.mail the seller's sending domain https://mail.example.test/sellers/{seller}
services/deal.ts:31 roles.closer.talk.calls the seller's calling number https://calls.example.test/bridge
services/deal.ts:42 meet.guard held the meeting's calendar https://calendar.example.test/events
services/deal.ts:20 output.contract the seller's contract and e-sign https://sign.example.test/contracts
pools/closers.ts:10 door closers.deals, and its verifier https://closers.deals/door.json
6 connections · 5 the seller's own, made once in its portal · 1 the door's| Dependency | In the sandbox | The contract a real one meets |
|---|---|---|
The seller's Stripe account, behind outcome.proof and the close's pay_link | https://stripe.example.test/sellers/{seller} | connected at the seller's first order, with read access and the one write that drafts the close's invoice; that invoice carries metadata.deal, and its customer is the account; without the connection deploy --live refuses proof_unconnected |
| The mandate | spt_…, a sandbox token | a scoped payment token or a saved bank mandate, good up to the order's max_usd, with the seller's consent sentence on the record |
The sending mailbox, roles.closer.talk.mail | https://mail.example.test/sellers/{seller} | the seller's domain authorizes api.forsale to send as it; every reply lands on the deal's thread |
The calling number, roles.closer.talk.calls | https://calls.example.test/bridge | a number the seller owns, bridged to the closer; each call is recorded to the thread with its length |
The calendar, behind meet.guard | https://calendar.example.test/events | reports each attendee's email domain and minutes in the meeting |
The contract, output.contract | https://sign.example.test/contracts | returns the signed file, hashed on the record |
The door, door: 'closers.deals' | https://closers.deals/door.json | the door's terms, pinned at their version; its verifier writes each member's facts, a license included |
| Live keys | — | sk_live_ keys, which take real orders and charge real money |
| Payouts | — | api.forsale's payout account, which receives the 5% and pays every member; a live order answers payouts_unconfigured until it is connected |
| Firms | — | a firm that enrolls its bench on closers.agency and is paid for them |
Connect each of the seller's systems in the customer portal, or let the order's OFFER ask for them. Run check, then the brand's own suite, then api.forsale's, and run one deal on a test key end to end, from the order to the payout. Then take live keys and connect payouts. Deploy takes the folder live, and Operate is what running it looks like.