· Andrei M. · Product Management · 9 min read
Managing Products, Categories & Attributes via API: Authentication, Endpoints & Rate Limits
A developer-focused guide to the REST API surface for product data: API key vs. bearer token auth, core endpoints, response envelopes, pagination, and rate limit handling.
Managing Products, Categories & Attributes via API: Authentication, Endpoints & Rate Limits
If you are building a custom storefront, a middleware layer between your PIM and an ERP, or an internal tool that needs to read and write catalog data on its own schedule, the admin UI and file-based imports eventually stop being enough. The question becomes: which REST API features should you actually use to manage products, categories, and attributes programmatically, and how do you authenticate and rate-limit those calls without breaking a production integration?
This guide is written for developers. It covers the authentication models a product API typically exposes, the endpoint shapes you should expect for creating, updating, and listing products, how pagination and response envelopes usually work, and how to design an integration that survives rate limits instead of failing on the first large batch. Where useful, it points to MicroPIM’s own REST API reference and Integration Sync API reference for exact, current specifications, since endpoint contracts evolve and a blog post is the wrong place to freeze them.
REST API vs. File Import vs. Integration Sync API
Most PIM platforms, MicroPIM included, expose more than one way to move product data. Picking the wrong one is a common source of integration pain.
- File-based import (CSV, XLSX, JSON, XML, feed URLs) fits batch data from a supplier or marketplace where you don’t control the source format. MicroPIM’s import feature covers Link, Bulk, File, Feed, and Website import with AI-assisted field mapping — usually less code than a custom API client for a one-time or supplier-driven load.
- A general-purpose REST API fits cases where your own system needs to read or write individual products, categories, or attributes on demand — a custom admin tool, a reporting dashboard, or a small-volume automation.
- An Integration Sync API (a dedicated endpoint set for two-way sync) fits a persistent, ongoing connector rather than a one-off script — pushing catalog changes out and reconciling state on a recurring basis.
A mature integration often uses file import for the initial bulk load, then an API for incremental updates afterward. MicroPIM’s import automation overview and integrations page are a reasonable starting point before writing any API code.
Authentication: API Keys and Bearer Tokens
Product APIs generally use one of two authentication patterns, and a platform often exposes both for different purposes.
API key in a request header. A static key, generated in account settings, sent on every call. MicroPIM’s core REST API, documented at docs.micropim.net/reference/rest-api, uses an X-API-KEY header, with requests missing a valid key rejected as 401 Unauthorized. This suits server-to-server integrations where the key lives in an environment variable, never in client-side code.
Bearer tokens issued per integration. For persistent, scoped integrations, a token-issuance flow is more appropriate than one shared key. MicroPIM’s Integration Sync API works this way: an integration is created through a connect endpoint that returns an api_token, sent afterward as Authorization: Bearer <api_token>. Tokens carry scopes (read, write, admin), and a separate disconnect call revokes the token when the integration is removed — better suited to a distributable connector, since each customer’s integration gets its own token.
Regardless of model: never hardcode keys or tokens in a repository or client-side bundle, rotate them periodically, request the narrowest scope available, and treat a 401 as a signal to check credentials rather than retry blindly.
Core Endpoints for Products, Categories, and Attributes
A REST API for product data typically groups endpoints around three resources, each following CRUD conventions plus a few catalog-specific extras.
| Resource | Typical operations | Notes |
|---|---|---|
| Products | List (with filters), get by ID, create, partial update, delete, barcode/EAN lookup | Create usually requires at least a name and SKU; delete is commonly a soft delete |
| Variants | List variants for a product, get a single variant | Nested under the parent product |
| Categories | List, get tree, get children, create, update, delete, assign products, move | Tree/children endpoints exist because categories are hierarchical |
| Attributes | List, get by ID, create, update, delete | Maps to attribute types, properties, and groups |
| Channels | List configured publishing channels | Useful for tooling that needs to know where a product can publish |
A typical create payload is a JSON object with required fields (commonly name and SKU) and optional fields for price, category, and attribute values. A typical update uses a partial-update method (PATCH) so you send only changed fields — smaller payloads, and less risk of overwriting a field another process just changed.
List endpoints almost always support filtering and pagination: query parameters for search, status, brand, or channel, plus page and page-size parameters with a sensible upper bound. Read the pagination metadata in the response rather than assuming a fixed page count.
A well-designed API wraps every response in a consistent envelope — a status flag, a data field, and an error field that’s null on success. Parsing against that stable envelope, rather than the raw resource body, makes your client more resilient to small schema changes over time. Treat docs.micropim.net/reference/rest-api as the source of truth for exact endpoints and required fields — API surfaces evolve faster than articles about them.
Rate Limits: Designing an Integration That Doesn’t Fall Over
Production APIs enforce rate limits, and read endpoints commonly tolerate more volume than write endpoints, since writes cost more to validate. Exceeding the limit typically returns 429 Too Many Requests rather than a silent failure.
- Exponential backoff with jitter. On a
429, wait before retrying, increasing the wait on each subsequent failure, with a small random offset so concurrent clients don’t retry in lockstep. - Respect rate-limit headers when provided. Remaining-quota and reset-time headers let you throttle proactively instead of waiting for a rejection.
- Batch where the API allows it. A bulk endpoint that accepts multiple records per call beats looping one record at a time — MicroPIM’s Integration Sync API, for example, accepts multi-product pushes up to a documented per-request cap rather than one call per product; check the current reference for the exact limit.
- Build idempotency into writes. For any sync that might retry after a timeout, key creates and updates to your own SKU or an external ID, so a retry updates the same record instead of creating a duplicate.
This is standard defensive design for any third-party API. What’s different with catalog data is that a duplicate or malformed write doesn’t just fail loudly — it can silently propagate to every connected sales channel, which is exactly the failure mode idempotency prevents. For more on propagation delay and partial failures in multi-channel sync generally, see the real-time sync architecture breakdown.
Building Two-Way Syncs with an Integration Sync API
A general product CRUD API is enough for scripts and internal tools, but a persistent connector — one that keeps a storefront’s catalog and your PIM in sync continuously — usually needs more: a way to register the integration, monitor health, and push or pull changes in bulk on a schedule.
MicroPIM’s Integration Sync API is built for this. It handles products, variants, SKUs, prices, stock, categories, brands, images, attributes, and SEO fields — deliberately not orders or customers, which stay the storefront’s or ERP’s responsibility. In practice: an integration registers once and receives a scoped token; status endpoints (authenticated and a lightweight public check) let you monitor connection health without polling the full catalog; and product pushes are batched, with mapping endpoints to look up how a MicroPIM product ID corresponds to the record on the other side — essential for avoiding duplicate creation when the same product is pushed twice.
The deciding question between the general REST API and a sync API is durability: a script touching a handful of records occasionally fits the REST API fine; a connector meant to run unattended for months and reconcile drift is better served by an API purpose-built for sync, with mapping and health-check primitives already in place.
Key Takeaways
- Separate “get data in once” (file import) from “keep data in sync” (REST or Integration Sync API) — they solve different problems.
- Expect a static API key in a request header, or a scoped bearer token issued per integration; use the narrowest scope you need.
- Products, categories, and attributes generally follow CRUD conventions, with categories adding tree/hierarchy operations and products supporting partial updates.
- Design for rate limits up front: backoff, batching, and idempotent writes keyed to your own SKU or external ID.
- For a persistent connector, a purpose-built Integration Sync API with health checks and mapping endpoints is worth the extra setup versus scripting against the general API.
Frequently Asked Questions
Which REST API features should I use to programmatically manage products, categories, and attributes? Use the resource-specific CRUD endpoints: list and get-by-ID for reading, create and partial-update for writing, plus catalog extras like category tree/children endpoints and product-to-category assignment. Manage attribute values through the dedicated attribute endpoints, not the product endpoint alone. Check MicroPIM’s REST API reference for the current, exact endpoint list.
How can I authenticate and rate-limit API calls when integrating product data with external systems? Authenticate with whichever model the API documents — a static API key in a request header for server-to-server calls, or a scoped bearer token issued through a connect flow for a persistent integration. For rate limiting: read the documented limits, implement exponential backoff with jitter on 429 responses, batch writes where supported, and make retried writes idempotent so a retry never creates a duplicate.
What endpoints and payload formats are common for creating, updating, and listing products via API? Creating a product is usually a POST with a JSON payload requiring at least a name and SKU, plus optional price, category, and attribute fields. Updating is usually a PATCH with only the changed fields. Listing supports query-parameter filters (search, status, brand, channel) plus pagination, with responses wrapped in a consistent envelope (status, data, error).
Do I need the Integration Sync API if I already use the general REST API? Not necessarily. Occasional reads or writes from an internal tool fit the general REST API fine. A connector meant to run continuously and reconcile catalog drift without manual intervention is better built on a dedicated Integration Sync API with token scopes, health checks, and ID mapping — see MicroPIM’s Integration Sync API reference.
Ready to build against a real product API instead of piecing one together from imports? Explore MicroPIM’s REST API reference and features overview, or start a free trial to get your API key and test against a live catalog.
Building a connector for a platform not listed in our integrations page? Contact our team — we can walk through whether the REST API or Integration Sync API is the better fit for what you’re building.
