younifyd
Menu

Connectors

Pimberly Connector

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

On this page

What this connector is for

Manages products, attributes, categories, digital assets, and webhooks in Pimberly, a Product Information Management (PIM) platform, via its real REST API. Requires a Connection with your Pimberly API Key (found in Pimberly under Settings → API Keys) — sent as the raw Authorization header value on every request, not a Bearer prefix.

Pimberly's Webhooks actions call a separate host from every other action here — a region-specific Webhooks API, distinct from the core /core/* API the Product and Asset actions use. Both use the same API key.

Reading the response

Every action's step output has the same top-level shape, readable from later steps 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.

Pimberly's API is not consistent about nesting its own body in a further data field. List endpoints, and two of the product-mutation endpoints, wrap their real payload in { ..., data: ... } — for those, you need {{<stepReference>.response.data.data.<field>}}, one level deeper. Every action section below states which shape it actually returns, confirmed against Pimberly's own documented example responses — not assumed.

Products

List Products

Configuring it

  • Limit (limit) — optional, sent as the limit query parameter. Maximum products per page. Pimberly's own default is 64 if omitted.
  • Attributes (attributes) — optional, sent as the attributes query parameter. Pipe-separated list of attribute names to return per product (e.g. desc|size|color), or omit for every attribute. Only valid for feed API keys, per Pimberly's own docs.
  • Show Sequence Number (showSequenceNumber) — optional, sent as the showSequenceNumber query parameter. Also returns each attribute's sequence number where set.
  • Include Empty (includeEmpty) — optional. Wire-name mismatch: sent to Pimberly as the include_empty query parameter (snake_case), not includeEmpty.

Response

Pimberly's real example response is paged and wraps the product list in its own data array:

{
  "status": "success",
  "count": 47,
  "total": 47,
  "next": "https://sandbox.pimberly.com/api/v2.2/products?sinceId=...",
  "previous": "https://sandbox.pimberly.com/api/v2.2/products?maxId=...",
  "data": [
    { "_link": "...", "id": "62fd04d55ef36700186a0537", "primaryId": "FINC_SHRT004_BLU_18S" }
  ]
}
  • {{<stepReference>.response.data.count}} / {{<stepReference>.response.data.total}} — this page's size and the store-wide total.
  • {{<stepReference>.response.data.data}} — the array of {_link, id, primaryId} products (one extra .data — see the connector-wide note above).
  • {{<stepReference>.response.data.next}} — the full URL for the next page. Pimberly returns a 404 once you page past the end, which is expected and means there are no more pages — not an error condition to alert on.

For example, a step named "List Products" (reference listProducts) — read the first result's Primary ID with {{listProducts.response.data.data.0.primaryId}}.

Get Product

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment: GET /core/products/:primaryId.

Response

Flat — no nested data wrapper. Pimberly's own documented example is minimal:

{ "id": "62fd04d55ef36700186a0525", "primaryId": "FINC_SHRT004_WHT_18S" }
  • {{<stepReference>.response.data.primaryId}} — e.g. {{getProduct.response.data.primaryId}} for a step named "Get Product".

Create Product

Configuring it

  • Primary ID (primaryId) — required, sent in the request body.
  • Schema ID (schemaId) — required, sent in the request body.
  • Type ID (typeId) — optional, sent in the request body if set (e.g. a variant-grouping name such as "Size").
  • Attributes (attributes) — optional JSON object of attribute name/value pairs, sent in the request body under attributes if set.

Request: POST /core/products.

Response

Unlike Get Product, Pimberly wraps this response in its own data field:

{
  "data": {
    "status": "success",
    "message": "Created EXAMPLEPRODUCT001",
    "primaryId": "EXAMPLEPRODUCT001",
    "id": "64dcdc11a2490c016591bf46"
  }
}
  • {{<stepReference>.response.data.data.primaryId}} / {{<stepReference>.response.data.data.message}} — the extra .data is real here (see the connector-wide note above).

Update Product

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment: PUT /core/products/:primaryId.
  • Schema ID (schemaId) — optional, sent in the request body if set.
  • Type ID (typeId) — optional, sent in the request body if set.
  • Attributes (attributes) — optional JSON object of attribute name/value pairs to set (merged into the existing product, not a full replace), sent in the request body under attributes if set.

Response

Same wrapped shape as Create Product:

{ "data": { "status": "success", "message": "Updated EXAMPLEPRODUCT002", "primaryId": "EXAMPLEPRODUCT002", "id": "64ddf1befbb404017dcbf082" } }
  • {{<stepReference>.response.data.data.message}}.

Delete Product

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment: DELETE /core/products/:primaryId.

Response

No example response is documented in Pimberly's own reference for this endpoint — expect a confirmation body at {{<stepReference>.response.data.*}}, but the exact fields aren't confirmed. Check {{<stepReference>.response.status}} for success (2xx) rather than relying on a specific body field.

Get Product Attributes

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment: GET /core/products/:primaryId/attributes.

Response

Flat — every attribute is a top-level field alongside id/primaryId, no nested data wrapper:

{ "id": "62fd04d55ef36700186a0525", "primaryId": "FINC_SHRT004_WHT_18S", "desc": "Double cuff long sleeve shirt from the FashionINC Premier Collection", "size": "18S" }
  • {{<stepReference>.response.data.<attributeName>}} — e.g. {{getProductAttributes.response.data.desc}}.

Update Product Attribute

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment.
  • Attribute Name (attributeName) — required, sent as a path segment: PUT /core/products/:primaryId/attributes/:attributeName.
  • Value (value) — required, sent in the request body as { "value": ... }. This replaces the attribute's value — for a merge across multiple attributes at once, use Update Product's attributes field instead.

Response

Flat, no nested data wrapper:

{ "status": "success", "message": "Updated EXAMPLEPRODUCT001", "primaryId": "EXAMPLEPRODUCT001", "id": "64dcdc11a2490c016591bf46" }
  • {{<stepReference>.response.data.message}}.

Delete Product Attribute

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment.
  • Attribute Name (attributeName) — required, sent as a path segment: DELETE /core/products/:primaryId/attributes/:attributeName.

Response

No example response is documented in Pimberly's own reference for this endpoint. Check {{<stepReference>.response.status}} for success.

Get Product Categories

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment: GET /core/products/:primaryId/classes.

Response

{ "status": "success", "count": 1, "data": [ { "path": "Men / Clothes / Smart Shirts", "ids": ["62fd07f906d8984780d46f3f", "62fd07f906d8984780d46f70", "62fd07f906d8984780d46f7f"] } ] }
  • {{<stepReference>.response.data.data}} — the array of {path, ids} category assignments (the extra .data is real here). ids is the path of class IDs from root to leaf — the last entry is what Remove Product Category's classId expects.
  • For example, {{getProductCategories.response.data.data.0.path}}.

Add Product Category

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment: PUT /core/products/:primaryId/classes.
  • Category (class) — required, sent in the request body as { "class": ... }. The category name, e.g. "T-Shirts".

Response

Flat:

{ "status": "success", "message": "Added class T-Shirts to PIM_0001" }
  • {{<stepReference>.response.data.message}}.

Remove Product Category

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment.
  • Class ID (classId) — required, sent as a path segment: DELETE /core/products/:primaryId/classes/:classId. The leaf ID from Get Product Categories' ids array.

Response

Flat:

{ "classId": "5c8128bb599de430eb00000b", "message": "Deleted 5c8128bb599de430eb00000b from PIM_0001", "primaryId": "PIM_0001", "status": "success" }
  • {{<stepReference>.response.data.message}}.

Get Product Children

Configuring it

  • Primary ID (primaryId) — required, sent as a path segment: GET /core/products/:primaryId/items. The parent product's Primary ID.

Response

{ "status": "success", "total": 3, "page": 0, "limit": 64, "data": [ { "id": "62fd04d55ef36700186a051f", "primaryId": "FINC_SHRT004_WHT_16S" } ] }
  • {{<stepReference>.response.data.data}} — the array of child {id, primaryId} items (the extra .data is real here — this is a different, paged shape from Get Product Categories' array, with its own total/page/limit, not count).
  • For example, {{getProductChildren.response.data.data.0.primaryId}}.

Assets

Get Asset

Configuring it

  • Asset Slug (assetSlug) — required, sent as a path segment: GET /core/assets/:assetSlug.

Response

No example response is documented in Pimberly's own reference for this endpoint. Check {{<stepReference>.response.status}} for success and inspect {{<stepReference>.response.data}} for the real shape.

Add Asset Tags

Configuring it

  • Asset Slug (assetSlug) — required, sent as a path segment: POST /core/assets/:assetSlug/tags.
  • Tags (tags) — required, sent in the request body as { "tags": [...] }. A JSON array of tag strings.

Response

No example response is documented in Pimberly's own reference for this endpoint.

Delete Asset Tags

Configuring it

  • Asset Slug (assetSlug) — required, sent as a path segment: DELETE /core/assets/:assetSlug/tags.
  • Tags (tags) — required, sent in the request body as { "tags": [...] } (DELETE with a body).

Response

No example response is documented in Pimberly's own reference for this endpoint.

Add Asset Comment

Configuring it

  • Asset Slug (assetSlug) — required, sent as a path segment: POST /core/assets/:assetSlug/comments.
  • Comment (comment) — required, sent in the request body as { "comment": ... }.

Response

No example response is documented in Pimberly's own reference for this endpoint.

Webhooks

These three actions call Pimberly's separate Webhooks API host, not api.pimberly.io — see "What this connector is for" above.

List Webhooks

Configuring it

No input fields — GET /webhooks.

Response

Pimberly's own body here is a bare array, not an object with its own data field — so there's no extra nesting despite this being a list endpoint:

[
  { "name": "example-webhook", "enabled": true, "url": "https://example.com", "headers": { "x-optional-header": "example-value" }, "trigger": "products", "actions": ["create", "update"], "secret": "optional-secret", "email": "optional-email@example.com", "failCount": 0, "dateCreated": "2023-08-17T13:18:11.515Z", "dateUpdated": "2023-08-17T13:18:11.515Z" }
]
  • {{<stepReference>.response.data}} is the array directly. For example, {{listWebhooks.response.data.0.name}}.

Create Webhook

Configuring it

  • Name (name) — required, sent in the request body. Must be unique.
  • URL (url) — required, sent in the request body. Where Pimberly POSTs when the webhook fires.
  • Trigger (trigger) — required, sent in the request body, e.g. "products".
  • Actions (actions) — required JSON array, sent in the request body, e.g. ["create", "update"].
  • Enabled (enabled) — optional, sent in the request body. Defaults to true if not explicitly set to false.
  • Headers (headers) — optional JSON object, sent in the request body if set. Extra headers to include on the webhook's own outbound request.
  • Secret (secret) — optional, sent in the request body if set. A shared secret for signing the webhook payload.
  • Notification Email (email) — optional, sent in the request body if set. Notified on repeated webhook failures.

Request: POST /webhooks.

Response

Flat, no nested data wrapper — mirrors the request plus Pimberly-assigned fields:

{ "name": "example-webhook", "enabled": true, "url": "https://example.com", "headers": { "x-optional-header": "example-value" }, "trigger": "products", "actions": ["create", "update"], "secret": "optional-secret", "email": "optional-email@example.com", "failCount": 0, "dateCreated": "2023-08-17T13:18:11.515Z", "dateUpdated": "2023-08-17T13:18:11.515Z" }
  • {{<stepReference>.response.data.name}} / {{<stepReference>.response.data.failCount}}.

Delete Webhook

Configuring it

  • Webhook Name (webhookName) — required, sent as a path segment: DELETE /webhooks/:webhookName.

Response

No example response is documented in Pimberly's own reference for this endpoint. Check {{<stepReference>.response.status}} for success.

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}}:

{{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:

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

Referencing trigger data

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

Referencing workflow variables

{{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:

{{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.