Where the Exchange plugs into EEI.
Five groups, ordered by launch criticality. Direction says who calls whom; everything server-to-server is authenticated service-to-service — the browser never touches these APIs directly.
Identity — one enthusiast, every site
| Integration | Direction | How | Phase |
|---|---|---|---|
| Single sign-on | Exchange → EEI IdP | EEI identity provider speaking OpenID Connect; Sharetribe consumes it natively. One login for FI, CO & Exchange. | Launch |
| Account linking (existing customers) | One-time migration | First SSO login matches on verified email → links or creates the marketplace account; unverified emails get a claim flow, never silent merges. | Launch |
| Profile & garage sync | EEI → Exchange | Display name, avatar, saved vehicles → Sharetribe user extended data (powers "fits my car" + gallery links). | Launch |
| Session / logout policy | Decision | Single credential, per-site sessions. Decide: does logging out of FI end the Exchange session? (Recommend: no — independent sessions, shared login.) | Decide wk 1 |
Money — the wallet (see §02) + settlement
| Integration | Direction | How | Phase |
|---|---|---|---|
| Store-credit wallet | Both ways | THE decision — two architectures compared below. Either way: Sharetribe Integration API event on sale completion → credit accrues; EEI checkouts redeem. | Launch |
| Settlement & reconciliation | Exchange → EEI finance | Nightly ledger export (sales, escrow state, credits issued/redeemed, cash-outs) → data warehouse; three-way reconcile vs Stripe + Sharetribe. | Launch |
| Tax feed | Exchange → tax engine | Marketplace-facilitator sales into the existing engine/filings; confirm current state registrations cover P2P (they likely do). | Launch |
| Refund / claims money-path | Ops runbook | Claims resolve inside Stripe (escrow never released); credit clawbacks only for post-release reversals — rare, dual-control required. | Fast follow |
Data — our moat feeding their platform
| Integration | Direction | How | Phase |
|---|---|---|---|
| Catalog spec service | Exchange → EEI catalog | Read API: brand/model → size, offset, bolt pattern, bore, weight, MSRP. Powers listing prefill AND the automated spec-check bot. | Launch |
| Fitment / YMM | Exchange → EEI fitment | The same engine FI/CO use — called as a service, not copied. Vehicle → spec envelope → marketplace search filters at launch; fast-follow: spec-check stamps per-listing fitment metadata for instant "fits your car" chips + gallery-verified-on-your-chassis badges. | Launch |
| Plate / VIN decode | Exchange → vendor | Same third-party decode service class retail uses; feeds the YMM finder. | Fast follow |
| Gallery cross-links | Both ways | Listing stores gallery build ID; gallery builds show "parts for sale" chips. Deep links both directions. | Fast follow |
| Sold-comps pricing data | Internal | Exchange sale history → "what's it worth" bands; seeded from retail pricing until organic volume exists. | Post-launch |
Commerce — the flywheel touchpoints
| Integration | Direction | How | Phase |
|---|---|---|---|
| Cross-site navigation | Static | Superheader links both ways (already designed in this demo). | Launch |
| Email / ESP audience sync | Exchange → ESP | Exchange signups + saved-search alerts into the existing email platform; suppression lists honored both ways. | Fast follow |
| Analytics & attribution | Both → warehouse | Shared analytics property or rollup; tag credit-funded retail orders so the flywheel is measurable ("Exchange drove $X of new-parts revenue"). | Launch |
| Checkout add-on upsells (FI-fulfilled items in a peer order) | Exchange → FI OMS | Custom line items + order relay into FI fulfillment — real integration work, scoped separately. | Roadmap |
Operations — the humans and the boxes
| Integration | Direction | How | Phase |
|---|---|---|---|
| Shipping labels + tracking | Both ways | EasyPost/Shippo on our carrier accounts; purchase on payment, tracking webhook fires the delivered→inspection transition. | Launch |
| Support tooling | EEI support → Exchange | Existing support team gets Sharetribe Console access + order-lookup; one phone number, both businesses (as the demo's help page already promises). | Launch |
| Fraud & risk signals | Both ways | Shared device/email blocklists across properties; Exchange KYC status visible to risk tooling. | Fast follow |
Universal wallet: two ways to build it.
Sellers earn credit on the Exchange and spend it at FI, CO, and every EEI storefront. The question is who owns the ledger.
One ledger, every property integrates
A new standalone wallet service inside EEI infrastructure. FI cart, CO cart, and the Exchange all call it. The Exchange is just one credit source among future ones (returns, promos, loyalty).
- Cleanest long-term: one balance, one truth, every future program plugs in
- Cost: new service PLUS integration into both retail carts before launch
- Puts the wallet on the critical path of the shared cart — the codebase we're deliberately not touching
We own the ledger, EEI sites call our API
The Exchange's server-side service owns the credit ledger (it's the only credit source at launch anyway). EEI checkouts call our API to check balance, place a hold, and capture on order completion.
- Fastest to launch: retail carts only add a "redeem credit" call at checkout — no new shared infrastructure
- Exchange accrual is internal (same service that hears the Sharetribe webhook)
- Risk to manage: don't let it fragment — see the callout
Build B with A's contract. Ship the Exchange-side ledger, but design the API as if it were the universal wallet from day one — property-agnostic endpoints (balance · authorize-hold · capture · release · statement), no Exchange-specific assumptions. If EEI later stands up a central wallet service, it adopts the same contract and the retail carts never change a line. The decision that must be made this week: does the shared cart already have any store-credit/gift-card ledger? If yes, Option B's API wraps it instead.
"Insanely secure," specified.
Store credit is cash-equivalent. These aren't nice-to-haves — they're the build spec for the wallet API, whichever option wins.
Server-to-server only
Browsers never call the wallet API. Only site backends do, over mTLS + short-lived, audience-scoped JWTs (OAuth2 client-credentials, one client per property, least-privilege scopes).
Append-only double-entry ledger
No balance field to overwrite — balance is derived from immutable entries. Every entry carries actor, source event, and hash-chain to its predecessor. Adjustments are new entries, never edits.
Two-phase redemption
Authorize-hold → capture on order completion; auto-release on timeout or cancel. Idempotency keys on every mutation — a retried request can never double-spend or double-credit.
Signed webhooks, replay-proof
Credit accrual fires from the Sharetribe completion event: HMAC-signed, timestamped, nonce-tracked — a replayed or forged webhook mints nothing.
Human controls
Manual adjustments require dual approval; full audit log of every read and write; secrets in a vault with rotation; access reviews. SOC2-style controls even before a SOC2.
Fraud & abuse limits
Velocity limits on accrual and redemption, anomaly alerts, device fingerprint on redemption, KYC-gated accrual (already required for payouts). Breakage & liability accounting defined with finance on day one.
Wheels
Wheel + Tire Sets
Tires 
Suspension
Performance
Aero + Body
Interior
Deals