An automated release pipeline for the Plugins Library — what works on other platforms

We maintain a plugin that ships to five different extension marketplaces, and our release process is fully automated on four of them. The fifth is zen-cart.com, where "automation" currently means a Selenium script on a workstation pretending to be a logged-in browser. Since a release API is on the table, here's what we've learned shipping to all of them — who gets it right, and what we'd want here.

Adobe Commerce Marketplace (EQP) is the one to model. Real API: developer app credentials, a technical-review submission endpoint that takes the package zip plus metadata. Our CI pushes a git tag, builds the marketplace zip, runs a static scan against their coding-standard rules, and submits — nobody opens a web form. Marketing review stays human, which is fine. It's strict and a bit bureaucratic, but it works end to end.

Shopify versions your app config and extensions through shopify app deploy and the Partners API. The listing is submitted once through the partner dashboard; every release after that is a CLI call. Good model for "reviewed once, released many times."

BigCommerce barely counts as a marketplace upload — apps are hosted, so there's no per-release zip. We deploy our backend on merge and push storefront script changes through their official Scripts API. The listing is still a web form, and that's okay because listings change rarely. Lesson: the release path and the listing path are different things, and only the release path needs an API.

WordPress.org has no REST API either, yet it automates cleanly because SVN is a protocol, not a form — Stable tag in readme.txt drives the directory and our script mirrors the release zip into trunk and creates a tag. The killer feature isn't the transport, though. It's Plugin Check: an official static-analysis job we run in CI before tagging, so bad submissions die on our runner instead of in a moderator's queue. That saves everyone time, reviewers included.

What we'd ask for, minimum viable version:

• API keys per author account (or OAuth client credentials). Anything except session cookies and CSRF tokens, so CI can authenticate.
• A versioned release endpoint — zip as multipart or an artifact_url + sha256, with version, changelog, and Zen Cart/PHP compatibility ranges as fields, not free-form description text.
• Idempotent submits — re-posting the same version updates the pending release instead of creating a duplicate row.
• A status endpoint (pending / approved / rejected + reviewer notes). A webhook on review completion would be better still, but polling is fine.
• A dry-run flag that validates metadata and packaging without creating a release — the wp.org Plugin Check trick. Catching bad submissions client-side cuts moderator load too.
• Keep the web form. The API should be additive. First listing stays manual and moderated; the API covers releases after the plugin ID exists — that's already how Adobe splits it.

POST /api/v1/plugins/2441/releases
Authorization: Bearer zc_rel_...

{
  "version": "1.4.0",
  "changelog": "...",
  "zc_version_min": "1.5.8",
  "zc_version_max": "2.1.x",
  "php_min": "8.0",
  "artifact_sha256": "…",
  "artifact_url": "https://…"
}

→ 201 { "release_id": 812, "status": "pending_review" }

GET /api/v1/plugins/2441/releases/1.4.0
→ { "status": "approved", "published_at": "2026-11-10", "reviewer_notes": "" }

One bonus worth designing in from the start: the same read endpoint doubles as an update feed. If GET /api/plugins/{id}/latest existed, in-store Plugin Managers could check for updates against a canonical source instead of screen-scraping the download page. We already do this on our own site — a signed manifest.json with an ed25519 signature over the zip's sha256, verified by the plugin before it offers an update — and it took an afternoon to wire up.