Skip to main content

​
Will the webhooks always include the merchant SKU?

Yes, webhooks that include variant data always provide your retailer SKU in the variant.identifier field. You’ll also find the supplier’s SKU in the brand_identifier field.

​
What should a merchant expect to receive in the following fields on webhooks:

"shipments": [], "cancels": [], "memos": [], "tags": [], "invoices": [], "rmas": [], "credits": [], "order_batches": [], "metadata": [], "envelopes": []
If an order has related data for these fields, the complete JSON objects are included directly in the webhook payload, not just an array of IDs.

​
What does the connection_id represent?

The connection_id identifies the unique relationship between a retailer and a specific brand. It stores all the configuration details for that connection, such as options, credentials, feeds, adjustments, and SLAs. fabric includes this ID on all order-related webhooks.

​
What is the difference between local_due_amount and due_amount?

The due_amount is the invoice total, including adjustments (such as allowances and charges), expressed in your default currency. The local_due_amount is that same amount converted to the user’s currency preference in fabric. These two amounts will be identical if the brand and retailer share the same currency.

​
What is invoice_acceptance? Does the merchant need to return an acceptance status on invoices?

invoice_acceptance is an optional feature. You can choose to accept or reject an invoice. If an invoice is rejected, a reject_reason must be provided. For details on how to use this feature, please refer to the merchant API for acknowledging and rejecting invoices, or the invoices UI documentation.

​
Why does fabric disable a webhook after 10 consecutive failures?

Disabling a webhook after repeated failures is a deliberate safeguard to protect system reliability, security, and user experience. fabric recognizes that this approach has tradeoffs. Disabling a webhook can result in missed events if the endpoint is down temporarily, and not all failures indicate the same level of severity (for example, a temporary 500 error versus a permanent 404). However, allowing a webhook to fail indefinitely introduces larger risks. The 10-failure threshold helps fabric:
  • Prevent notification overload by stopping repeated delivery attempts to an endpoint that is consistently unavailable, which could otherwise strain internal queues and downstream systems.
  • Maintain system stability by avoiding endless retry loops to non-functional endpoints.
  • Address potential security concerns, as persistent failures may indicate misconfiguration or malicious behavior.
  • Improve visibility and user experience by clearly signaling that action is required, rather than allowing silent, ongoing failures.
This behavior aligns with industry standards and balances reliability, security, and transparency. Once the underlying issue is resolved, the webhook can be re-enabled to resume event delivery.