younifyd
Menu

Pimberly Connector

Manage products, attributes, categories, digital assets, and webhooks in Pimberly (a Product Information Management platform) as workflow steps.

Browse 19 Pimberly actions pimberly
On this page

What this connector is

Manages products, attributes, categories, digital assets and webhooks in Pimberly, a Product Information Management (PIM) platform, through its REST API.

Connecting

Create an API Key connection with your Pimberly API key (Pimberly: Settings → API Keys). The key is sent as the raw Authorization header value on every request, with no Bearer prefix.

Two hosts are involved, both using the same key:

  • The core API (https://api.pimberly.io, paths under /core/*) serves the Product and Asset actions.
  • The Webhooks API is a separate, region-specific service used by the Webhook actions. It defaults to https://webhooks-api.eu-west-1.service.pimberly.com; a connection whose config sets webhooksApiUrl overrides that host.

Your first call

  1. Add a step with the List Products action and name it "List Products" (reference listProducts).
  2. Pick your Pimberly connection and optionally set Limit.
  3. Read the first product's Primary ID with {{listProducts.response.data.data.0.primaryId}}.
  4. Pass it to a later Get Product step as its Primary ID.

Every action, with its parameters and response fields, is listed in the action reference.

How actions are organised

  • Products — list, get, create, update and delete products; get, update and delete a single attribute; get, add and remove categories; get a parent's children.
  • Assets — get an asset, add and delete tags, add a comment (all addressed by asset slug).
  • Webhooks — list, create and delete webhooks (on the separate Webhooks host).

Request conventions

  • Identifiers such as Primary ID, Attribute Name, Class ID, Asset Slug and Webhook Name are path segments; everything else is a query parameter or JSON body field as shown in the action reference.
  • Wire-name mismatch: on List Products, the Include Empty field (includeEmpty) is sent to Pimberly as the snake_case include_empty query parameter. The Attributes filter on List Products only works for feed API keys, per Pimberly's own docs.
  • Update Product merges its attributes into the existing product rather than replacing it. Update Product Attribute replaces the one attribute's value; use Update Product to change several at once.
  • Remove Product Category takes the leaf class id: the last entry of an ids array returned by Get Product Categories.
  • Delete Asset Tags sends its tags as a JSON body on a DELETE request.

Reading the response

Every action's step output has the same top-level shape, read via its Step Reference, written here as <stepReference>:

  • {{<stepReference>.response.status}} / {{<stepReference>.response.statusText}} — the HTTP status of the call to Pimberly.
  • {{<stepReference>.response.headers.<header-name>}} — a response header.
  • {{<stepReference>.response.data.<field>}} — Pimberly's own response body, one level in.

The extra data level

Pimberly's API is not consistent about wrapping its own body in a further data field. These shapes are confirmed against Pimberly's documented example responses:

  • Extra data level — read {{<stepReference>.response.data.data.<field>}}:
    • List Products (a paged body with status, count, total, next, previous and a data array of {_link, id, primaryId}).
    • Get Product Children (paged with total, page, limit and a data array of {id, primaryId}).
    • Get Product Categories (status, count and a data array of {path, ids}).
    • Create Product and Update Product, which wrap {status, message, primaryId, id} in data.
  • Flat — read {{<stepReference>.response.data.<field>}}: Get Product (id, primaryId), Get Product Attributes (every attribute is a top-level field next to id/primaryId), Update Product Attribute, Add Product Category, Remove Product Category (each status + message), and Create Webhook (mirrors the request plus failCount, dateCreated, dateUpdated).
  • Bare array — List Webhooks returns an array directly at {{<stepReference>.response.data}}, with no wrapper despite being a list (for example {{listWebhooks.response.data.0.name}}).
  • No documented example — Delete Product, Delete Product Attribute, Get Asset, Add Asset Tags, Delete Asset Tags, Add Asset Comment and Delete Webhook have no example response in Pimberly's reference. Check {{<stepReference>.response.status}} for success (2xx) and inspect {{<stepReference>.response.data}} rather than relying on a field name.

Pagination

List Products returns a page of at most Limit products (Pimberly's own default is 64) with the full URL of the next page at {{<stepReference>.response.data.next}}. Pimberly returns a 404 once you page past the end; that is expected and means there are no more pages, not a failure to alert on. Get Product Children pages with total/page/limit rather than count.

Error handling

Pimberly errors do not throw. A failed call returns Pimberly's real error body and status as the step output, for example {"error": {"statusCode": 401, "message": "Authorization Required", "code": "AUTHORIZATION_REQUIRED"}}, so branch on {{<stepReference>.response.status}}. If Pimberly can't be reached the step returns status 503 with "Failed to connect to Pimberly API".

Common tasks

Create a product and set its attributes

  1. Run Create Product (named "Create Product", reference createProduct) with a Primary ID, a Schema ID and optional Attributes, for example {"desc": "Double cuff shirt", "size": "18S"}. The new product's id is at {{createProduct.response.data.data.primaryId}}.
  2. Run Update Product Attribute with that Primary ID, the Attribute Name size and Value 16S to change one attribute.
  3. Confirm with {{updateProductAttribute.response.data.message}}.

Re-categorise a product

  1. Run Get Product Categories and read the current path at {{getProductCategories.response.data.data.0.path}}.
  2. Run Remove Product Category with the leaf class id from that entry's ids.
  3. Run Add Product Category with the new category name, for example T-Shirts.

Subscribe to product changes

Run Create Webhook with a unique Name, the URL Pimberly should POST to, Trigger products and Actions ["create", "update"]. Enabled defaults to true. Optionally set a Secret for signing and a Notification Email for repeated failures.

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

  • Must be at least 2 characters, and 50 characters or fewer.
  • Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
  • Can't be empty.

Tips

  • Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
  • Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

text
{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

text
{{steps[0].response.data.id}}

Referencing trigger data

text
{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

text
{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

text
{{runtimeVariables.myVariable}}

Notes

  • If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
  • Object values are automatically JSON-stringified when interpolated into a string field.

Execution Settings

Fire-and-forget

When enabled, the workflow doesn't wait for this step to complete before moving to the next one. Use it for steps whose result nothing downstream depends on — logging, analytics, notifications — so they don't add latency to the steps that matter.

Continue on error

When enabled, a failure in this step doesn't stop the workflow — execution continues to the next step. The failure is still recorded in the execution history; this just controls whether it's fatal.

Combine the two for steps that are genuinely optional to the outcome: fire-and-forget so they don't add latency, continue-on-error so a failure in them (e.g. an analytics endpoint being briefly down) doesn't take down an otherwise-successful workflow run.

Caching

What it does

When enabled, a step's result is cached for a configurable TTL (time-to-live, in seconds). If the step runs again with the same effective cache key before the TTL expires, the cached result is returned instead of re-running the step.

Configuring it

  • Enabled — turn caching on or off for this step.
  • TTL — how long (in seconds) a cached result stays valid.
  • Cache key template — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same call". By default this is based on the step's resolved input; a custom template lets you cache more narrowly or broadly than that.

When to use it

Good candidates are steps that call something slow or rate-limited but return the same answer for the same input within a short window — a lookup against a rarely-changing external system, for example. Skip it for steps whose result must always be fresh (anything involving live inventory, pricing, or payment state).

Locking

What it does

When enabled, only one execution of this step (for a given lock key) can run at a time. If a second execution tries to run the same step while a lock is held, it waits until the lock is released or the hold period elapses.

Configuring it

  • Enabled — turn locking on or off for this step.
  • Lock key — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same resource". By default the lock is scoped to the step itself; a custom key lets you lock per-customer, per-order, or any other identifier that needs serialized access.
  • Period — how long (in seconds) the lock is held before it's automatically released, in case an execution doesn't complete normally.

When to use it

Use it whenever concurrent executions could race on the same resource — e.g. two workflow runs both trying to update the same order's status at once. A lock key scoped to the order id ensures only one of them proceeds at a time.

Was this page helpful?

Last updated 9 October 2026