Permanent deletion — no undo: This operation immediately and permanently removes the product from the Facebook Catalog. Any active WhatsApp product messages referencing this product ID will display an error or broken product card to customers. Always verify the product ID before calling this node and log the deletion to an audit trail. If you need to temporarily hide a product, use commerce/updateProduct to set availability to out of stock instead.
When to Use
- End-of-life product retirement: When a product is discontinued in the ERP system, a product lifecycle workflow removes it from the WhatsApp catalog, ensuring customers can no longer add discontinued items to their cart and preventing failed orders.
- Flash sale cleanup: After a flash sale ends, a cleanup workflow deletes the promotional product variants that were created specifically for the sale period, keeping the catalog clean and preventing customers from viewing expired prices.
- Regulatory compliance removal: When a product is recalled or banned for sale in certain markets, a compliance workflow immediately removes it from the relevant WABA catalogs, ensuring it is no longer accessible via WhatsApp commerce in those markets.
- Catalog deduplication: A data quality workflow identifies duplicate product entries in the catalog (same retailer ID, different Facebook product IDs created by idempotency failures) and deletes the duplicate entries, keeping one authoritative record per SKU.
- Seller offboarding: When a seller deactivates their account on a marketplace platform, an offboarding workflow removes all of that seller's products from the shared WhatsApp catalog, preventing orphaned listings after the seller relationship ends.
Configuration
Connection
| Field | Required | Description |
|---|
accessToken | Required | Permanent System User access token from Meta Business Manager. Store in BizFirst Credentials Manager and reference via {{ $credentials.whatsAppToken }}. |
phoneNumberId | Required | Numeric string ID of the WhatsApp Business phone number (e.g. 123456789012345). |
apiVersion | Optional | Meta Graph API version, e.g. v18.0. Defaults to v18.0. |
Operation
| Field | Required | Description |
|---|
productId | Required | The Facebook catalog product item ID to permanently delete (e.g. 9876543210123). This action cannot be undone. |
Sample Configuration
{
"resource": "commerce",
"operation": "deleteProduct",
"accessToken": "{{ $credentials.whatsAppToken }}",
"phoneNumberId": "123456789012345",
"productId": "{{ $input.catalogProductId }}"
}
Validation Errors
| Error | Cause |
|---|
accessToken is required | The accessToken field is empty or missing. |
productId is required | The productId field is empty or missing. |
100 (Meta) | The product ID does not exist or the System User lacks delete access to the catalog. |
200 (Meta) | Permissions error — the token lacks catalog_management permission. |
190 (Meta) | Access token expired or revoked. |
Output
Success Port
Fires when Meta confirms the product has been deleted. The productId field confirms which product was removed. Update your internal database immediately to mark this product as deleted and remove any workflow configurations referencing this product ID.
| Field | Type | Description |
|---|
success | boolean | true on the success port. |
productId | string | The Facebook product ID that was deleted. Store in an audit log immediately. |
status | string | "deleted" on the success port. |
errorCode | string | Empty on success. |
errorMessage | string | Empty on success. |
payload | string | Full raw JSON response from the Meta Graph API ({"success":true}). |
Error Port
Fires when the deletion fails. A failure does NOT mean the product was deleted — always check status before updating your database.
| Field | Type | Description |
|---|
success | boolean | false on the error port. |
status | string | "failed" or "error". |
errorCode | string | Meta error code or BizFirst internal validation code. |
errorMessage | string | Human-readable error description. |
payload | string | Raw API error response for diagnostics. |
Sample Output
{
"success": true,
"productId": "9876543210123",
"status": "deleted",
"errorCode": "",
"errorMessage": "",
"payload": "{\"success\":true}"
}
Expression Reference
| Value | Expression | Notes |
|---|
| Deleted product ID | {{ $output.deleteProduct.productId }} | Write immediately to an audit log and update your products database to mark this ID as deleted. |
| Status | {{ $output.deleteProduct.status }} | Must be "deleted" before updating your internal database. Never mark a product as deleted based solely on reaching the success port — verify the status field. |
| Error code | {{ $output.deleteProduct.errorCode }} | Non-empty on error port. A Meta 100 error means the product was already deleted — safe to mark as removed in your database. |
| Full API response | {{ $output.deleteProduct.payload }} | Raw JSON response. {"success":true} confirms deletion at the Meta API level. |
Node Policies & GuardRails
| Policy Area | Recommendation |
|---|
| Credential storage | Always store the access token in BizFirst Credentials Manager. Never embed raw tokens in node configuration fields. |
| Irreversibility safeguard | Add a human-approval step before this node in any non-automated workflow. For automated deletion workflows, require a secondary confirmation field (e.g. a flag set by a separate approval node) to prevent accidental deletions triggered by data errors. |
| Audit trail requirement | Always write to an audit log immediately after successful deletion. Record the product ID, product name (retrieved before deletion), deleted-by workflow name, and timestamp. Deletion audit logs are required for regulatory compliance in many markets. |
| Order idempotency | Before deleting a product, check whether any open orders reference this product ID. Products with pending orders should not be deleted until those orders are fulfilled or cancelled, as deletion may cause order fulfilment systems to fail when looking up product details. |
| Internal database sync | After a successful deletion, immediately update your internal products database to remove or tombstone the record. Failure to do so will result in broken product message attempts when other workflows try to reference the deleted product ID. |
| Error port handling | Always connect the error port. A failed deletion should halt any downstream steps that assume the product is no longer in the catalog. Do not silently swallow deletion errors. |
Examples
Flash Sale Cleanup — Delete Promotional Variants
{
"resource": "commerce",
"operation": "deleteProduct",
"accessToken": "{{ $credentials.whatsAppToken }}",
"phoneNumberId": "123456789012345",
"productId": "{{ $item.flashSaleProductId }}"
}
A ScheduledTrigger fires when the flash sale ends. A ForEach node iterates over the flash sale product IDs stored during the sale's creation phase. This node deletes each promotional variant. On success, the workflow marks each entry in the flash_sale_products table as deleted. Products where deletion fails are flagged for manual review in a support queue.
Discontinued Product Retirement from ERP
{
"resource": "commerce",
"operation": "deleteProduct",
"accessToken": "{{ $credentials.whatsAppToken }}",
"phoneNumberId": "123456789012345",
"productId": "{{ $input.catalogProductId }}"
}
An ERP event fires when a product's lifecycle status changes to "discontinued". The workflow first calls commerce/getProduct to retrieve the product name and saves it to an audit record. Then this node deletes the product. On success, the audit record is marked complete with the deletion timestamp. The audit database provides a full history of all products ever removed from the catalog.
Catalog Deduplication
{
"resource": "commerce",
"operation": "deleteProduct",
"accessToken": "{{ $credentials.whatsAppToken }}",
"phoneNumberId": "123456789012345",
"productId": "{{ $item.duplicateProductId }}"
}
A data quality workflow runs weekly, listing all products via commerce/getProducts and grouping them by retailer ID. Where multiple Facebook product IDs exist for the same retailer ID, all but the most recently created one are passed to this node for deletion. Only the canonical record (lowest creation time) is retained. The workflow sends a deduplication summary report to the commerce team after each run.
