Skip to main content

Fishbowl Dealers Integration

This integration customizes WooCommerce REST product API behavior for the Fishbowl API account and adds request logging for auditing and troubleshooting.

Reference file: wp-content\themes\suma-elementor\inc\integration\class-fishbowl.php

Overview​

The integration is implemented in the Suma\Integration\Fishbowl class which registers two WordPress filters:

  1. woocommerce_rest_product_object_query - API filtering
  2. rest_post_dispatch - API request logging

These filters only apply special behavior for a dedicated Fishbowl user account.

Fishbowl User Scope​

  • Fishbowl API user ID: 1026
  • Log source: fishbowl-integration-api

If the current user is not ID 1026, the integration exits early and does not alter behavior.

Product Sync Date Logic​

What It Changes​

For requests to /wc/v2/products, from user 1026 that include an after parameter, the integration changes filtering from product publish date to product modified date.

Default WooCommerce behavior typically uses post_date for date queries. This integration rewrites it to:

  • post_modified when dates_are_gmt is empty

  • post_modified_gmt when dates_are_gmt is present

  • request status to publish

  • query post_status to publish

This prevents non-published products from being included in Fishbowl sync responses.

Why It Matters​

Before filtering, the Fishbowl API requests product data using the after parameter to pull products published after the timestamp. This timestamp then updates to the last run sync. Should any products not sync correctly, on the next sync they will be missed. This can then cause downstream issues of order data failing in Fishbowl.

With the updated filtering, product requests will only return published or updated products to Fishbowl with the after key. This keeps the Fishbowl data fresh with catalog updates and only pushed published product data into the Fishbowl system.

Request Logging​

All REST responses for Fishbowl user 1026 are logged through WooCommerce logger using source fishbowl-integration-api.

Logged Request Data​

The logger captures:

  • user_id
  • route
  • method
  • params
  • query_params
  • body_params
  • json_params
  • body

Additional Product Endpoint Logging​

For /wc/v2/products, the integration also logs:

  • returned_item_count
  • returned_skus

returned_skus is built by collecting non-empty sku values from response items, trimming whitespace, and de-duplicating entries.

Sanitization and Redaction​

Before logging, request payload values are sanitized recursively.

Sensitive Key Redaction​

Values for these keys are replaced with [REDACTED]:

  • consumer_key
  • consumer_secret
  • authorization
  • password
  • token
  • api_key
  • access_token
  • refresh_token

Pattern-Based Credential Redaction​

String values are scanned for WooCommerce API-style tokens matching:

  • ck_*
  • cs_*

Detected matches are replaced with [REDACTED].

Long Value Truncation​

Strings over 2000 characters are truncated and suffixed with ...[TRUNCATED].

Request Flow Summary​

  1. REST request arrives.
  2. If route is /wc/v2/products, user is 1026, and after exists:
  3. Query date filter is switched to modified date column.
  4. Product status is forced to publish.
  5. Response is generated by WooCommerce.
  6. On dispatch, if user is 1026, request details are sanitized and logged.
  7. For /wc/v2/products, SKU and response count metadata are added to logs.

Operational Notes​

  • Integration is intentionally scoped to one service account to avoid side effects for admin or storefront users.
  • Logging occurs only when the result is a WP_REST_Response.
  • If Fishbowl sync misses updates, confirm the after value format and server timezone/GMT handling.
  • Review WooCommerce logs filtered by source fishbowl-integration-api during sync debugging.