> ## Documentation Index
> Fetch the complete documentation index at: https://developer.fabric.inc/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhook FAQs

## 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](/v3/dropship/api-reference/merchant/invoice/acknowledge-invoice-by-id) for acknowledging and rejecting invoices, or the [invoices](/v3/dropship/dropship-retailers/orders/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.