Ingest a WooCommerce product webhook (Partner API)

Accepts a single WooCommerce product webhook event for a partnership using bearer authentication. This endpoint is intended for partnerships and accepts:

• a Cognito bearer token for the partner user linked to the listing source, or
• an Aura Historia access token owned by that partner user.

The caller must provide:

• the bearer token in the Authorization header,
• the WooCommerce topic in x-wc-webhook-topic, and
• the base64-encoded HMAC-SHA256 signature over the exact, untouched request body bytes in x-wc-webhook-signature, and
• optionally, the WooCommerce delivery identifier in x-wc-webhook-delivery-id.

A supplied delivery identifier applies only when an event maps to raw capture. Its provider receipt retains only a canonical semantic source-payload SHA-256 evidence digest for 90 days. A captured-observation retry with the same digest may be deduplicated during downstream capture; reuse with different evidence fails in the consumer, not as an immediate HTTP 409. Logical receipt expiry permits a new receipt but never removes or rewrites a captured raw revision or its provenance. A timestamp-free DELETE establishes a restore barrier. A later UPSERT without a provably newer date_modified_gmt fails during downstream capture (WOOCOMMERCE_PROVIDER_SOURCE_ORDER_AMBIGUOUS), not as an immediate HTTP 409. Admission does not create a provider receipt or raw revision; investigate the failed FIFO command before reconciliation or redrive. The service verifies the signature over untouched body bytes before JSON parsing, then submits mapped observations as CAPTURE_RAW to the shared FIFO after bearer/capability checks and source configuration lookup. The consumer checks the current partner/source grant for mapped observations; ignored no-ops check it immediately. Only a matching, confirmed queue acceptance permits 204; rejected, oversized, unconfirmed, and not-attempted submissions are not acknowledged. The FIFO consumer later commits raw capture with the command receipt; provider receipt and source-order decisions occur during that capture. Authorized ignored create/update events are no-op 204 without queue send or receipt, even when they include a delivery identifier. Retry an uncertain submission with the same signed body, topic, source, actor and delivery identifier where provided; without a delivery identifier, retries cannot recover the original command identity after a lost reply and have no provider receipt-based deduplication guarantee. A lost reply may already have enqueued work; never infer rollback from a non-204.

Topic-specific payload requirements:

• every topic requires id
• product.created and product.updated with status: publish capture an UPSERT and require nonblank name and permalink
• product.created and product.updated with status: trash, draft, pending, or private capture a DELETE and require only id; missing or unsupported statuses are authorized ignored events and also require only id
• product.deleted captures a DELETE and requires only id

The listing source identified by listingSourceId must have a WooCommerce ingestion configuration with a nonblank write-only webhookSecret and a configured language. A nonblank price maps to a SET and requires the listing source to have woocommerceCurrency configured.