reship — matching unfulfilled orders to returned stock across the warehouse network

a shopify brand ships ~98% of orders through its main fulfiller. the other 2% get reshipped from returned stock sitting across several warehouses. that reconciliation was living in separate, differently-shaped spreadsheets. reship replaces it: one supabase-backed app, per-warehouse logins with row-level-security isolation, and a cloudflare worker holding the shopify credentials so the browser never sees a token.

the shopify pull was the first fight. spring '26 killed the static shpat_ token — dev-dashboard apps only hand you a client id + secret now, so the worker does a client-credentials grant, caches the 24h token, and refreshes it. then the count didn't match the admin: 79 orders pulled vs 123 in shopify. it was the 60-day orders limit — the list api silently caps unless you hold read_all_orders. oldest order returned was exactly 58 days back. not a bug, a platform rule.

the matcher is two-phase on purpose: "find matches" proposes region-locked 1-to-1 pairings (size normalized per product), then the admin culls and bulk-assigns. unmatching a proposal used to cascade — free an item and it'd instantly re-match to another order — so unmatched items now get set aside for the round. once assigned, only the warehouse can pull it back, until they mark it picked.

shipped: live matching, frozen/lost/picked statuses, a self-serve CSV/Excel importer that maps columns and auto-matches products, inline + bulk inventory editing, soft-delete with a 60-day purge, and a vendor admin panel that mints logins via a service-role worker endpoint. all EN/中文. the live demo runs on fully synthetic data. the one thing still manual: the operator marks the shopify order fulfilled by hand — the app flags the match, it doesn't write back to shopify yet.