ZingaShopSign in

Generic Resources

Generic Resources

Beyond the purpose-built endpoints, the API exposes a large set of catalog,
marketing, shipping and store-configuration objects through a uniform
list / read / create / update / delete pattern at /{resource}. Learn it once
and it works the same for every resource in the table below.

Requires data:read to read and data:write:* to write.

The pattern

Method Path Purpose
GET /papi/v1/{resource} List (supports limit, offset, q, filters, websiteId)
GET /papi/v1/{resource}/{id} Read one
POST /papi/v1/{resource} Create
PATCH /papi/v1/{resource}/{id} Update
DELETE /papi/v1/{resource}/{id} Delete (soft-delete where supported)

List responses use the standard { data, total, limit, offset } envelope. A
delete returns { "deleted": true, "id": "…" }. As everywhere, responses carry
each field in both camelCase and snake_case (see Conventions).

# List the ten most recent promotions
curl "https://api-v1.zingasuite.com/papi/v1/promotions?limit=10" \
  -H "Authorization: Bearer zk_live_xxx"

Available resources

Group Resources
Catalog tags, collections, attribute-sets, attributes, brands
Storefront config currencies, languages, tax-zones, tax-rates
Customers customers, customer-groups, reviews
Marketing & content promotions, coupons, gift-cards, cms-pages, blog-categories, blog-posts, banners, menus
Pricing pricelists
Subscriptions subscription-plans, subscriptions
Digital goods digital-assets, entitlements
Inventory & sales warehouses, returns
Shipping shipping-zones, shipping-methods
Search search-synonyms, search-redirects
URLs url-redirects
Carriers carrier-integrations
Payments payment-gateways

products, orders, inventory and websites have their own purpose-built
endpoints — use those pages, not the generic layer. Calling the generic layer
for one of them returns use_dedicated_endpoint:<resource>.

What each field accepts

The exact create/update fields differ per resource. To discover them, read one
existing row (GET /{resource}/{id}) and mirror its field names in your
request — every readable field name is a valid input name (in camelCase or
snake_case).

Operations that aren't available

Some resources are read-only over the API, or are created only through a
dedicated flow (typically because they handle secrets or need side effects).
Attempting an unavailable operation returns a clear 405:

  • resource_not_creatable — this resource can't be created via the API.
  • resource_not_updatable — this resource can't be updated via the API.

Resources that hold credentials or secrets (for example payment-gateways and
carrier-integrations) never return those secrets in responses and can't be
created through the generic layer — configure them in the console.

Was this helpful?