eBay Sell API integration for pa.gf.cx/ebay-seller — PARKED

DARE.CO.UK · PARKED SKETCH · 2026-05-23

Mirrored from ~/.claude/.../memory/project_ebay_seller_api_integration_parked.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

Parked 2026-05-20. Manual ledger is fine while listing volume is low. Build Phase A (developer registration + OAuth + ebay_pull.py + renderer) when listing volume ≥10 OR payout reconciliation becomes load-bearing OR a sibling integration (Etsy/Mercari) becomes interesting. ~3-4 hr active work, $0 cost.


Dan, 2026-05-20:

“park as sketch with resume conditions, fascinating idea”

Full sketch: ~/Downloads/parked_sketch_ebay_seller_api_integration_2026-05-20.md (also published to reports.dare.co.uk/parked_sketch_ebay_seller_api_integration_2026-05-20 on next catalog deploy).

Revenue baseline (added 2026-05-20)

Dan: “We are doing about $3000 per year on ebay”

At ~$3k/year: - Roughly $250/month gross - If average sale is $20-50, that’s ~5-12 transactions/month, ~60-150/year - Active listings at any moment likely 3-15 (depends on turnover rate) - Manual ledger is sustainable but already friction — ~10 entries/month is noticeable - Payout reconciliation noticeable — could be 1-2 payouts/month to track

This baseline shifts the resume math: the API integration would already pay for itself in attention at current volume. The blocker isn’t whether it’s worth it — it’s whether the cumulative friction has hit Dan’s “this is annoying enough to fix” threshold. Watch for explicit complaints about manual entry OR a desire for a month-end summary that doesn’t exist today.

Status — 2026-05-21 evening

Phase 0 COMPLETE — eBay developer keys APPROVED 2026-05-21 (fast-track, next business day after 2026-05-20 registration).

Dan: “fyi - approved - https://developer.ebay.com/my/keys”

Resumption gated only on: 1. ✅ ~~eBay approval email~~ — DONE 2. Dan drops App ID / Cert ID / Dev ID into op://Code Shared/eBay Sell API/{app_id,cert_id,dev_id} (custom concealed fields per the discipline) 3. Dan pings me to start the build

Next build path: OAuth dance in sandbox → ebay_pull.py skeleton → validate against sandbox data → submit for production keys → swap endpoints → ship. ~3-4 hr active work from here.

(Original registration confirmation: 2026-05-20 — fast-track approval inside one business day, on the optimistic end of the predicted Thursday/Friday/Monday window.)

Quick frame

pa.gf.cx/ebay-seller/ shipped today as a manual ledger — single transaction (Fabricio Lima refund). eBay has a full Sell APIs suite (modern OAuth 2.0) that would auto-populate every section the page currently stubs: listings, sales/orders, payouts & fees, disputes & cases.

Build path (when triggered)

Mirrors today’s gsc_pull.py pattern:

  1. developer.ebay.com registration (~10 min, free)
  2. OAuth user-consent dance → refresh token in 1Password (custom-named concealed field per the rule)
  3. ~/bin/ebay_pull.py — periodic pull → ~/Downloads/ebay_seller_<date>.md
  4. ~/bin/ebay_seller_render.py → updates pa/ebay-seller/index.html
  5. Sandbox first, then submit for production keys (hours-to-days approval)

Effort: ~3-4 hours active work. Cost: $0.

Resume conditions (build when ANY hold)

  1. ≥10 active listings — manual ledger becomes annoying
  2. Payout reconciliation matters — Dan wants auto monthly “you sold $X, paid $Y in fees, netted $Z” summary
  3. A second platform comes in scope — Etsy / Mercari / Poshmark / Reverb. eBay build becomes the template (same OAuth-pull-render shape)
  4. Tax season — auto-export all transactions for Schedule C / 1099-K
  5. Dispute volume — auto-capture means no gaps in case logging

Skip / defer

Cross-references

The aphorism

The first time it’s manual. The third time it’s an API. eBay is at one — we’ll know when it’s three.

Source: parked_sketch_ebay_seller_api_integration_2026-05-21.md · Rendered 2026-05-23 11:24