Product master (PIM) and category data

Product PIM Category SKU Data integration

Who this article is for
For developers who want to integrate product master (PIM) data. Used to sync with e-commerce, POS, and WMS.

ReceiptRoller's product represents the smallest sellable unit at the SKU level. When it has variations (size, color, etc.), it takes a two-tier structure of a parent product and child variations.

Main fields

Field	Contents
`id`	Product ID (`prd_`)
`sku`	A SKU code unique within the store
`jan_code`	JAN/EAN/UPC barcode (optional)
`name`	Product name
`price`	Standard price
`tax_rate`	Tax rate
`category_id`	Category
`parent_id`	Parent product (in the case of a variation)
`attributes`	Attributes such as size and color (free-form JSON)
`images[]`	Product image URLs

Related scopes

product.read — read the product master
product.write — create, update, delete products
category.read / category.write — operate categories

Main endpoints

GET    /v1/products             ← list (filterable)
GET    /v1/products/{id}         ← individual
POST   /v1/products              ← create
PATCH  /v1/products/{id}         ← partial update
DELETE /v1/products/{id}         ← delete (soft delete)
POST   /v1/products/batch        ← batch create / update
GET    /v1/categories            ← category tree

Best practices for SKU management

The SKU is unique within the store. Define a naming convention in advance
Storing the external system's ID in the external_id attribute makes re-syncing easier
When expanding variations, keep separate naming conventions for the parent SKU and child SKUs (e.g. SHIRT-001 / SHIRT-001-M-RED)
Prefer unpublishing (is_active=false) over deleting, so the links from past receipts remain

Synchronization patterns with e-commerce / POS

E-commerce → ReceiptRoller (master originates in e-commerce)

Treat the e-commerce product master as the source of truth and reflect it into ReceiptRoller via Webhook or a periodic batch. ReceiptRoller becomes the "reading side".

ReceiptRoller → POS

Manage products centrally on the ReceiptRoller side, and have the POS integration app receive the product.updated Webhook and distribute to each POS.

Two-way sync (caution)

Two-way sync requires conflict-resolution logic. Comparing updated_at, or deciding "which side is the master during which time window", is a realistic approach.

Related guides

Published: 2026-04-27 Updated: 2026-07-05

Back to help list