Yep Platform logo
REST API · Yep Platform Technical documentation for certified integrations

Categories

Create, update, paginated listing, query by ID, move in the tree and delete categories — with support for page, limit (up to 200), store_id and optional metadata via include_pagination.

Tree URL key Display mode Updated in 2026

Overview

Category routes cover the full lifecycle: create a new category in the tree, update metadata, list with deterministic pagination, query by ID, move within the hierarchy and delete.

200
Max limitPer page, when specified via limit.
20
Default limitWhen limit is omitted or invalid.
1+
Explicit storeDeterministic in multi-store environments.
opt
Metadatatotal, last_page, has_next with include_pagination=1.
POST/api2/category

Create a new category.

{
  "parent_id": 2,
  "name": "Especialidades",
  "position": 5,
  "is_active": 1,
  "is_anchor": 1,
  "include_in_menu": 1,
  "description": "Dental specialties category",
  "display_mode": "PRODUCTS",
  "url_key": "especialidades"
}
PATCH/api2/category

Update an existing category.

{
  "name": "Especialidades",
  "categoria": {
    "name": "New name",
    "description": "New description",
    "is_anchor": 1
  }
}
GET/api2/categoryUpdated

List categories with deterministic pagination, or fetch a single category by id.

GET /api2/category
GET /api2/category?page=2
GET /api2/category?limit=50
GET /api2/category?include_pagination=1
GET /api2/category?store_id=1
GET /api2/category?id=61
PATCH/api2/category/categoryMove

Move a category in the tree.

{
  "name": "Especialidades",
  "parent_name": "Produtos",
  "after_id": null
}
DELETE/api2/category

Delete a category.

{
  "category_id": 546
}

What's new in GET /api2/category

The category listing endpoint has been evolved to provide deterministic pagination, page-size control, explicit multi-store context and optional pagination metadata — aligning its behavior with GET /api2/products.

1) Paginated listing New

You can now walk through all categories with predictable pagination. Without page, the route returns the first page; with page=N, it returns the requested page.

page Optional New
Integer. Page number to return. Default: 1.

Example

GET /api2/category?page=2

2) Optional limit support New

The endpoint accepts limit to define how many records are returned per page. Invalid values (non-numeric, arrays, negative, zero or above the maximum) are normalized to the default, ensuring no request breaks due to unexpected input.

RuleValueBehavior
Default20Applied when limit is omitted.
Maximum200Hard ceiling to protect the route under high load.
InvalidInvalid values are normalized to 20.

Examples

GET /api2/category?limit=50
GET /api2/category?page=1&limit=200

3) Optional store_id support New

Pass store_id to make the result explicit and deterministic in multi-store scenarios. Without it, store selection follows the environment's default rule; with it, the integration takes control.

store_id Optional New
Integer. ID of the store to use as listing context. Recommended in any multi-store integration.

Example

GET /api2/category?store_id=1

4) Optional pagination metadata New

Optional pagination fields can now be added to the response body. They are only returned when include_pagination=1 is sent, avoiding overhead for sync routines that do not need this metadata.

include_pagination Optional New
Boolean flag (1 enables). When active, the response also contains total, last_page and has_next.
total
Total number of categories eligible for the current filter (only with include_pagination=1).
last_page
Number of the last page considering the current limit.
has_next
Boolean indicating whether there is a next page. Useful to safely terminate sync loops.

Example

GET /api2/category?include_pagination=1

5) Single fetch by id

Preserved and compatible: pass id to fetch a single category. When id is sent, pagination parameters are ignored.

Example

GET /api2/category?id=61

Supported usage patterns

Quick reference of the tested and approved combinations for GET /api2/category.

Default listing GET /api2/category
Paginated GET /api2/category?page=2
Custom limit GET /api2/category?limit=50
With metadata GET /api2/category?include_pagination=1
Explicit store GET /api2/category?store_id=1
By ID GET /api2/category?id=61

Integration recommendations

Best practices for syncing the category tree. Following these guidelines reduces rework, prevents infinite pagination and guarantees determinism in multi-store environments.

Recommended

  • Always send page explicitly in pagination routines.
  • Use store_id whenever the integration needs deterministic results in a multi-store environment.
  • Prefer limit=50 or limit=100 for regular syncs.
  • Use limit=200 only when there is a real need to reduce the number of calls.
  • Use include_pagination=1 to drive pagination loops safely (loop based on has_next).

Avoid

  • Sending parameters as arrays in scalar fields — for example id[] or limit[].
  • Relying on implicit ordering between pages in multi-store scenarios without store_id.
  • Combining id with page/limit: when fetching by ID, pagination parameters are ignored.

Sync tip

For recurring syncs of the category tree, combine store_id + limit=100 + include_pagination=1. You get determinism, balanced throughput and a reliable stop condition (has_next=false).