API Logs
Inspect request and response traffic for supported app integrations. Indexed PIM stores structured API log entries with payloads, status codes, events, timing, and app context so teams can debug sync work without guesswork.
API Request Logs
| Method | Endpoint | Status |
|---|---|---|
| GET | /v1/products/prod_123 | 200 |
| POST | /v1/inventory/sync | 201 |
| PATCH | /v1/products/prod_456 | 422 |
| GET | /v1/categories | 200 |
User-Agent: IndexedPIM-SDK/2.1.0
Latency: 156ms
Payload: {"sku": "NIKE-AM270", "stock": 45}
How API logging works
The app stores integration request history in the `ApiLog` entity. Each record belongs to an app and can include method, URL, request payload, response payload, HTTP status code, response time, event name, related product revision, and a microsecond timestamp.
Multiple integrations write to this shared log structure. WooCommerce, e-conomic, Rackbeat, e-conomic webhooks, and other integration clients all create log rows when they send or receive API traffic.
The app UI exposes a paginated API log screen per app, with queue counts shown alongside the log list so operations teams can see both recent traffic and pending sync work.
What is stored
Method or action type such as `GET`, `POST`, `IMPORT`, or `WEBHOOK`
Target URL and event label
Request and response payload bodies
Status code and response time
Related product revision when the log originated from product sync
Where the logs come from
API logging is shared infrastructure used by multiple integration modules.
WooCommerce Calls
The WooCommerce API client writes log entries for outbound requests, making it easier to inspect product, category, order, and sync failures.
e-conomic Sync
The e-conomic API client and download actions log both outbound API calls and import-style processing so teams can trace sync behavior end to end.
Webhook Traffic
Inbound webhook controllers write `WEBHOOK` log entries including query params, body, selected headers, result payload, and response timing.
Product Revision Context
When a product revision is involved, the log can keep a reference to that revision to help compare the API request against the exact catalog change that triggered it.
Paginated App Views
The app logs route fetches logs per app in descending created order with pagination, so users can focus on one integration instance at a time.
Queue Awareness
The log UI also surfaces queue counts for the selected app, which helps explain why a request has not been sent yet or whether work is still in progress.
Why the logs are useful operationally
A sync failed and nobody knows what was sent
Without request payload visibility, integration debugging turns into trial and error.
Solution:
API logs keep the request body, response body, status, event label, and timing in one record per call.
Webhook callbacks are hard to verify
Inbound webhook failures often disappear unless they are persisted explicitly.
Solution:
Webhook controllers create dedicated `WEBHOOK` log records with request details and processing results.
Large queues make status unclear
A missing external update may be a failure or simply pending async work.
Solution:
The app log page combines recent API history with current queue counts for the selected integration.
Product sync issues need better traceability
Catalog changes are difficult to debug when you cannot tie the API call back to the revision that triggered it.
Solution:
The log entity can link directly to a product revision when one is available.
Need visibility into what your integrations are actually doing?
Use the built-in API logs to inspect requests, responses, timing, and queue state for each connected app.