UnifyCart for Developers - API, Themes, Apps, Webhooks

Three ways in

Pick the Layer the Job Belongs In

A change to how a shop looks belongs in a theme. A connection to another system belongs in the API or a webhook. Something a shop owner installs and configures belongs in an app.

The API

Products, categories, orders, customers, the cart and inventory, over a versioned REST API with token auth, rate limits and conventional errors.

Read the API docs

Themes

Twig templates, a manifest, sections a shop owner can rearrange and settings they can change. No build step, no framework to learn.

Build a theme

Apps

Installed into a shop with the permissions it granted, its own API credentials, webhooks, script tags and a record of every charge.

Build an app

API access

A REST API That Behaves Itself

Bearer tokens you create and revoke from the admin, rate limits per token, paginated collections, and errors that say which field was wrong rather than just refusing.

The reference is generated from the code itself, so it describes what the API does today rather than what it did when somebody last wrote it up.

Browse the API Reference

GET /api/v1/orders

$ curl https://yourshop.com/api/v1/orders \
    -H "Authorization: Bearer uc_live_..."

{
  "data": [
    {
      "id": 1149,
      "order_number": "UC-1149",
      "status": "shipped",
      "payment_status": "paid",
      "grand_total": "441.46",
      "currency": "USD",
      "placed_at": "2026-10-02T19:16:48Z"
    }
  ],
  "meta": { "page": 1, "per_page": 25 }
}

What you get

The Parts That Usually Have to Be Built Twice

Most of the work in an integration is not the happy path. These are the pieces that make the rest of it survive contact with a real shop.

Webhooks with retriesConfigurable events, automatic retries and a delivery log you can read when something did not arrive.

Scoped permissionsAn app asks for what it needs and a shop grants it. Nothing gets blanket access to a merchant's data.

Per-token rate limitsLimits applied per token, so one noisy integration cannot take out another.

Generated referenceThe API documentation is generated from the code, so it cannot quietly go stale.

Script tagsAn app can put its own script on the storefront without a merchant editing a template.

Usage and chargesApp charges are recorded against the install, so billing for what you built is already handled.

Database per shopEach shop's data is in its own database, so one shop's volume is not another shop's problem.

Theme settings and sectionsDeclare them in the manifest and a shop owner gets real controls, not a stylesheet to edit.

Conventional errorsPredictable status codes and a body that names the field, so your client can act on a failure.

Marketplace

List What You Build, and Get Paid for It

Apps and themes both list in the marketplace. A shop owner finds yours, installs it, and the charge runs through the platform rather than through you.

The platform is built and the shelves are not full yet. If you build for shops, that is the opportunity rather than the catch.

See the Marketplace

1
Register as a developerOne account, which your apps and themes list under.
2
Build against a real shopStart a trial, point your app at it and work against the thing itself.
3
Submit for reviewNothing reaches a shop without passing review first, which is what makes installing safe.
4
Get installedInstalls, permissions and charges are recorded against your listing.

Start Building

The documentation is open to everyone, and the Discord is where the questions get answered.

Read the Developer Docs Join the Discord

Build on it, not around it