POS → WooCommerce REST stock-sync investigation (2026-04-30 → 2026-05-01)

POS_API_REPORT.md

POS → WooCommerce REST API: Stock Sync Investigation

Prepared for: POS integration team Date prepared: 2026-05-01 Window analysed: 2026-04-30 10:14 UTC → 2026-05-01 09:31 UTC (~23 hours) Source: Server-side access logs for the WordPress origin behind api.gqmobiles.lk

---

Summary

We investigated the report that some stock updates from the POS "occasionally fail / return blank response". Across the 23-hour window we examined, every single request from your POS consumer key was received in full and answered with a complete, well-formed response. Specifically:

Metric	Value
Total requests from POS consumer key	292
HTTP 2xx responses	292 (100%)
HTTP 4xx responses	0
HTTP 5xx responses	0
Authentication failures	0
Responses with body < 1 KB	0
Responses with body = 0 bytes (blank)	0
Smallest response body	2,438 bytes
Median response body	3,829 bytes
Largest response body	18,574 bytes

The full per-request log is attached as pos_requests.csv.

Key finding: The server has no record of a 200 OK with an empty body being returned to the POS in this window. Every POST to /wp-json/wc/v3/products/<id>/variations/<id> was answered with the full updated variation JSON (~2.5 KB on average).

If your POS application is observing HTTP 200 with an empty / unparseable body, that condition is not visible on the server side — the server believes it sent a complete response in every case. The most likely explanations therefore lie on the POS or network path.

---

What we saw your POS doing

Five client IPs were observed using the POS consumer key:

Client IP	Requests
175.157.20.31	100
112.134.136.188	76
112.134.142.192	72
112.134.142.39	42
112.134.217.199	2

Per request, the pattern is:

1. GET /wp-json/wc/v3/products/<variation_id> — read the current variation
2. POST /wp-json/wc/v3/products/<parent_id>/variations/<variation_id> — write the update

The split was an exact 146 GET / 146 POST — a healthy 1:1 ratio, which suggests every read was paired with a write attempt. We did not observe use of the /products/batch or /variations/batch endpoints from the POS consumer key.

All requests used HTTP/1.1 with HTTP Basic Auth (consumer key in the username field). No User-Agent was sent (logged as "-"), and no Referer was sent. This is fine, but see recommendation #4 below.

---

Reproducing the reported failure

We could not reproduce a 200 + blank body from the server logs. To investigate further we need one of the following from the POS team:

1. Two or three concrete failure cases, each with:
   • Wall-clock timestamp with timezone (UTC preferred) of the request
   • Source IP (the public IP of the POS terminal at that moment)
   • HTTP method, full path, request body
   • The response body the POS observed (even if blank — confirm "blank" means 0 bytes vs. JSON parse error vs. early connection close)
   • The HTTP response headers the POS observed (especially Content-Length, Content-Type, Connection, Transfer-Encoding)
2. Or, enable request/response logging on the POS HTTP client and capture a packet trace (e.g. curl --trace / tcpdump) of one failing request.

With timestamps and source IPs we can match the exact request line in the server log and confirm what the server actually sent, byte for byte.

---

What we recommend the POS team check

These are listed in order from most-to-least likely given what we see in the logs.

1. Read timeout on the POS HTTP client

Some variation updates can legitimately take several seconds (WooCommerce runs a number of post-save hooks). If the POS HTTP client has a short read timeout, it can receive the response status line + headers (200 OK) and then close the socket before the body finishes streaming, which the application code may then surface as "200 with blank body".

Action: confirm the read / response timeout in your HTTP client. We recommend at least 30 seconds for write endpoints. Log the elapsed time of every failed request — if "blank body" failures correlate with >= timeout, this is the cause.

2. Connection reuse / HTTP keep-alive bug

Some HTTP libraries reuse a pooled keep-alive connection that the server has already closed. The first request on the stale connection can read back what looks like a 200 with an empty body (because the actual bytes are from a half-closed channel). This is a known failure mode for older OkHttp, python-requests with custom pools, .NET HttpClient reused beyond its lifetime, etc.

Action: disable connection pooling for the WC REST client, or set a short pool idle timeout (e.g. 10s). Retry once on a "blank 200" before treating it as a failure.

3. JSON parser failing on a non-empty but unexpected body

200 + blank body is sometimes a misdiagnosis — the body is non-empty but the parser silently treats it as empty (e.g. UTF-8 BOM, surrounding whitespace, a Vary mismatch, or gzipped content the client didn't decompress). Server responses we observed are always >= 2438 bytes and JSON.

Action: when the POS sees a "blank" response, also log the raw byte length and the first 200 bytes of the body to a file. If the body is non-empty, the issue is in JSON parsing, not transport.

4. Make the POS requests identifiable

Currently every POS request logs User-Agent: "-" and Referer: "-". This makes incident triage slower for both sides.

Action: set a stable User-Agent like GQ-POS/<version> (terminal=<id>) on every request. This costs nothing and lets us instantly isolate POS traffic in a future investigation.

5. Idempotency / overwrite races (worth checking even if not the immediate issue)

The POS performs a GET then a POST. If a customer order is placed between those two calls, the order will reduce stock; the subsequent POS POST will overwrite the post-order value with the pre-order value the POS read. The POS would report this as "the API returned 200 but stock didn't change" — but actually stock did change, then was reverted by the POS itself.

Action: consider switching the write payload from {"stock_quantity": <absolute>} to a delta workflow, or include an If-Match / version check, or read-then-write with a server-side compare. At minimum, log on the POS side both the value sent and the value returned in the response — the response body always contains the new stock_quantity, and if it differs from what the POS sent, that's the race firing.

---

Server-side observations (for completeness)

• The server received the request, authenticated the consumer key, executed the WooCommerce update, and returned the full updated variation JSON in every request examined.
• No rate limiting, no firewall blocks, and no auth failures were applied to the POS consumer key.
• The endpoints being used (/wp-json/wc/v3/products/<id> GET and /wp-json/wc/v3/products/<parent>/variations/<id> POST) are correct and supported.

We're happy to run a deeper investigation on specific failed transactions as soon as the POS team can supply timestamps + IPs for them.

---

Attachment

• pos_requests.csv — every POS request logged at the server in the analysed window, with timestamp (UTC), client IP, HTTP method, endpoint, response status, and response body size in bytes.

pos_requests.csv

stock_changes_2026-04-29_to_2026-05-01.csv