Product data API Case study
Searchwiz Product Snapshot API
Searchwiz powers product search for our watch and jewelry catalog, and its feed requests originally landed on live WooCommerce queries. I wrote a plugin that answers those reads from a prepared snapshot table instead.
The business problem
A feed consumer that reads thousands of products will do it all day, every day. Assembling each response from live product objects, attributes, images and stock state was slow on our shared hosting and competed with actual shoppers for database time. The integration needed predictable data without a standing right to run expensive queries on demand.
What I delivered
- A dedicated wp_a2_searchwiz_snapshot table storing one normalized JSON document per product, with timestamps for change detection.
- REST routes under searchwiz/v1 (/products and /product) plus SnappPay-compatible v1/product/feed and v1/product endpoints served from the same snapshot.
- A cron batch builder on the a2_sw_snapshot_tick hook that processes 300 products per tick under a 45-second lock, plus a daily delta job that refreshes only changed products.
- A nonce-protected admin console with start-full, start-delta, run-once, stop and clear-snapshot actions.
- IP allowlisting with per-minute rate limits, 120 for /products and 300 for /product, enforced even for approved IPs.
Technical approach
- Separated snapshot generation from response serving so rebuild load and API load never stack on the same request.
- Went with IP allowlisting instead of API keys because the consumer publishes fixed crawler addresses; the a2_sw_allow_ips option extends the built-in list.
- Bounded every batch with the a2_sw_snapshot_time_budget filter so rebuilds cannot time out or spike memory.
- Made delta refresh timestamp-driven after the first full build, so daily maintenance touches only what changed.
Result and evidence
Moving reads onto the snapshot took the /products p95 from about 1.9s to 0.42s. Version 1.2.3 runs in production today and feeds both the Searchwiz integration and the SnappPay product feed.
Commercial value
The store can now hand its catalog to external consumers at a fixed, low cost per request, which turns integrations from a hosting risk into a sales channel.
Delivery notes
I owned this integration end to end: the data pipeline, the access policy and the tooling the team uses to operate it.
- Designed the snapshot schema and the batch state machine.
- Matched endpoint paths to the consumers' published documentation, including the SnappPay feed path.
- Put rebuild controls in wp-admin so maintenance never requires SSH.
Readable implementation brief
implementation_brief {
project: "A2 Searchwiz Product API"
stack: "WordPress plugin, PHP, WooCommerce, WP REST API"
version: "1.2.3"
routes: "searchwiz/v1/products, searchwiz/v1/product, v1/product/feed"
table: "wp_a2_searchwiz_snapshot, one JSON doc per product"
jobs: "a2_sw_snapshot_tick (300/batch, 45s lock), daily delta cron"
access: "IP allowlist; rate limits 120/min list, 300/min single"
result: "/products p95 1.9s -> 0.42s in production"
}What this project shows
Most WooCommerce APIs collapse under their own query weight; this one moves the expensive work onto a schedule the server controls. That inversion, prepare then serve, is my default answer to read-heavy integration problems.
A sanitized architecture walkthrough is public in the a2-searchwiz-product-api-showcase repository; real allowlist values, payloads and endpoint URLs stay private.