Catalog entities and relationships

Use the Public API to build and maintain your catalog from your own systems. Every resource below supports listing, reading one record, creating, updating and deleting within the project bound to your API key.

​

Available entities

Paths below are relative to https://wisepim.com/api/public/v1.

​

Common operations

For a resource such as keywords, use: Use the matching resource prefix for other scopes. Deletion is a separate permission: products:write does not grant products:delete. See the scope catalog and each endpoint for its exact path parameters and payload. Lists use cursor and limit with a maximum of 200 rows. Many support ids; product lists also support SKUs and incremental sync. Follow the filters declared on the individual endpoint. Send an Idempotency-Key on mutations and reuse it only for retries of that exact request. See retry rules.

​

Update only what you intend

PATCH changes only supplied fields. Omitting a field and sending null have different meanings; check the schema for fields that accept null. Unknown fields and changes to record identity, project or ownership are rejected. Related records must belong to the key’s project. An unavailable detail ID returns 404; an invalid relationship rejects the mutation. Category and family tree moves cannot create cycles. For code set values and units, code_set is required on creation and cannot be changed afterwards. Category and attribute reads retain their compact response shapes. Use category configuration or attribute configuration for the full configuration represented by their writable fields.

​

Permissions and resource-specific rules

• Prompts: reads follow the issuer’s visibility; only the owner can update or delete a prompt. Publishing a prompt publicly is not exposed through these writes.
• Knowledge: each project has one knowledge library. Creating a second returns 409; reading never creates one.
• Templates: these endpoints manage saved configuration. They do not launch imports or exports. Manage export-template attribute selections in the template editor.
• Relationships: use family attributes and product categories to manage bindings explicitly. Their IDs identify the binding record, not the product, family, attribute or category itself.
• Role permissions: scopes supplement the issuer’s current permissions. Resource management, product deletion and category membership retain their corresponding role or field permissions.

For work that processes a selection of products, use actions and jobs.