An open specification for dropshipping supplier APIs.
OpenDrop v1 defines a consistent REST surface that any dropshipping supplier can implement so that e-commerce platforms integrate once and consume many — instead of paying the integration tax separately for every supplier they connect to.
spec/v1.md— the full specification (18 sections, ~1,400 lines). Authentication, product / variant / inventory data model, discovery endpoints, bulk inventory & pricing, orders & shipping quotes, webhooks with HMAC signing, incremental sync, returns & refunds, localization, developer experience requirements (sandbox, OpenAPI, status page), a comparison table with four widely used suppliers, a suggested phasing for implementation, and an appendix case study of what platform-side integration looks like.reference-implementations/— list of suppliers that conform to OpenDrop (currently empty; first to ship gets listed).
openapi/— machine-readable OpenAPI 3.1 schema derived from the Markdown specexamples/— sample request / response payloads + reference webhook receiver implementations
These directories aren't in the repo yet. Open an issue or PR if you want to contribute either.
Every dropshipping API in the market today (CJ Dropshipping, Doba, BigBuy, Printful, Spocket, Wholesale2B, AliExpress DS, and dozens more) solves the same problems differently:
- Some use Bearer tokens, some use two-step
apiKey→accessTokenexchanges, some use RSA2 signatures. - Some return clean JSON, some embed stringified arrays in string fields, some put raw HTML in description fields.
- Some have webhooks, most don't.
- Some have idempotency keys, most don't.
- Some have sandbox environments, most don't.
- Some have proper error codes, most return
HTTP 200with{ "success": false }.
E-commerce platforms pay this fragmentation tax every single time they add a new supplier. Cumulative engineering hours wasted across the industry: huge. OpenDrop's bet is that one clean, modern spec adopted by enough suppliers makes the whole ecosystem 10x more productive.
- Spec version: v1.0
- License: MIT (see
LICENSE) - Maintainer status: light-touch. Authored by the team behind regen.store based on real integration experience. Issues + PRs are welcome but there's no community SLA — this is a reference document, not a managed project. Fork it, adapt it, take it in your own direction.
If you're building a dropshipping API right now, don't reinvent the
wheel. Read spec/v1.md. Every design choice has a
reason traceable to real integration pain — auth confusion, broken
JSON, missing webhooks, undocumented endpoint shapes. Implement the
spec and you'll skip 90% of the "your API broke our integration" tickets.
If you ship OpenDrop, open an issue and we'll list you
in reference-implementations/.
If you're consuming dropshipping APIs and tired of the integration treadmill, read the spec to understand what to demand from suppliers. The §18 appendix walks through what consuming an OpenDrop-compliant supplier looks like for an existing platform — broken into eight discrete work items (protocol extension, variant picker, multi-line orders, ship_to-aware stock checks, per-line shipping selection, webhook receiver, returns flow, idempotency-key plumbing). These are listed as implementation areas, not time estimates.
- Found a typo or unclear sentence? Open a PR directly against
spec/v1.md. - Want to propose a v1.x addition (new endpoint, new webhook event, new field)? Open an issue first, describe the use case, and we'll discuss before merging. We aim to keep v1 stable — additions only, no breaking changes within a major version.
- Want to propose v2 changes (breaking)? Same process; we'll batch v2 candidates and merge them into a v2 draft when there's enough signal.
MIT — fork freely, use commercially, no attribution required. We just ask that you keep the spec name "OpenDrop" so the ecosystem can refer to a single reference document.