Skip to main content

Salesforce restock

In the Salesforce Commerce Cloud (SFCC) integration, inventory restock is the merchant's responsibility.

J
Written by Jakub Talarek

What is it?

In the Salesforce Commerce Cloud (SFCC) integration, inventory restock is the merchant's responsibility. Ingrid Returns records the per-item restock decision made during quality check and makes it available via the Public API and outbound webhooks — but Ingrid never calls an SFCC inventory endpoint. Your system updates SFCC stock.

This follows the same webhook model as SFCC refunds and exchanges: Ingrid records and signals; your system acts.

How it works

  1. Returned items are received — via Quality Check, a connected WMS, or POST /merchant/items/returned.

  2. Each item gets a restock decision, stored as approvedForRestock.

  3. Ingrid records the decision and can emit a RETURN_QUALITY_CHECK_REPORT webhook event; it makes no SFCC inventory call.

  4. Your middleware reads the decision (webhook or Public API) and calls the SFCC inventory API for approved items only.

Item data available for restock

  • approvedForRestock — whether quality check approved the item

  • productVariant.sku / productVariant.foreignVariantId — to target the correct SFCC variant

  • returnedToWarehouseAt — the warehouse receipt timestamp

Configuration

  • Webhook: subscribe to RETURN_QUALITY_CHECK_REPORT in Returns Back-office → Integrations → Webhook Outgoing Subscriptions.

  • Public API: generate a key in Returns Back-office → Settings → API Keys for polling (a good fallback if a webhook is missed).

There are no SFCC-specific restock settings — approval comes from the quality check workflow, configured at shop level.

Examples

Real-time restock via webhook

Three items arrive; quality check approves two and rejects one (damaged). The webhook fires; your middleware increments SFCC stock for the two approved SKUs and skips the rejected one.

End-of-day batch via the Public API

A nightly job pulls the day's returns, collects items with approvedForRestock: true, and submits a single SFCC inventory batch update — no real-time infrastructure needed.

FAQ

SFCC inventory isn't updating after returns. Why?
Ingrid doesn't update SFCC inventory — your system must, from the webhook or Public API. Check your endpoint is receiving events and your integration logic runs.

How do I map a returned item to the SFCC product?
Use productVariant.foreignVariantId (the SFCC variant ID stored when the order synced).

Can an external WMS report restock instead of Quality Check?
Yes — POST /merchant/items/returned with a per-item approved flag populates approvedForRestock.

Our endpoint was down when items were approved.
Events aren't guaranteed to redeliver — poll GET /merchant/return to catch up on decisions from the outage window.

Limitations

Constraint

Detail

No automatic SFCC inventory update

Ingrid calls no SFCC inventory API; inventory management is fully on the merchant's side.

No SFCC-specific restock configuration

Approval decisions come from the quality check workflow; there are no SFCC-specific restock fields.

Per line item, not per unit

Approval covers the whole line-item quantity; partial approval within a line item isn't supported.

No automatic webhook redelivery

If your endpoint is down when an event fires, it isn't automatically resent — poll the Public API as a fallback.

Did this answer your question?