OroPocket
Raw API

Debug a failed call with request logs

Every request made with your key is logged — method, path, status, error code and latency — and appears within seconds. It is the fastest way to find out what your integration actually sent, as opposed to what you think it sent.

4 min read · 2 screenshots

Open Logs in the Build section. The three cards across the top summarise the last seven days: how many requests, what proportion failed, and average latency.

The Logs page of the OroPocket developer dashboard, showing request count, error rate and average latency cards above a table of API requests with columns for when, method, endpoint, status and latency.
Seven days of requests. The status column shows the HTTP code and, when there is one, the error code beside it.

  1. Filter to the failures

    Show errors only narrows the table to non-2xx responses and shows a count of how many of the total that is. On a healthy integration this is usually empty, which is itself the answer to “is it us?”

    The OroPocket Logs page filtered to errors only, showing failed API requests with red status badges carrying HTTP codes and error codes such as USER_CODE_NOT_FOUND and INVALID_ASSET.
    The error code is on the row — you rarely need to open anything to know what went wrong.

  2. Read the status badge

    The badge carries both halves: the HTTP status and the machine-readable code. Together they are almost always enough to identify the problem without reproducing it.

    You seeIt means
    403 API_NOT_ALLOWEDThe key does not carry the capability that endpoint needs. Fix it on the Capabilities page — no redeploy, no new key.
    401 INVALID_TOKENThe key is wrong, revoked, or replaced by a regeneration. Check which one your integration is actually sending.
    402 INSUFFICIENT_PARTNER_FUNDSYour billing account cannot cover the buy. See Top up your billing account.
    429 RATE_LIMITEDToo many requests from one IP. The partner API allows 120 a minute.
    429 SANDBOX_DAILY_LIMITSandbox is capped at 1,000 requests a day and resets at midnight IST. Live is not capped.

  3. Open Details for the request id

    Details expands a panel below the table with the endpoint, the status and a copyable Request ID. That id is the same value the API returned in the X-Request-ID header and in the request_id field of the response body.

    Quote the request id when you contact support. It resolves to the exact call, so nobody has to ask you to reproduce anything.

The logs follow the Test/Live toggle

You are looking at one mode at a time. A request that seems to be missing is very often a Live request being looked for in Test mode, or the reverse — check the toggle in the header before concluding a call never arrived.

What the latency column is telling you

Latency is measured server-side: our processing time, not the round trip from your infrastructure. If your own timings are much worse than what is shown here, the gap is network or client-side rather than ours. Quotes and confirmations are slower than reads because they take a price lock and write to a ledger.

Logs are retained for 30 days in sandbox. They are a debugging aid, not an audit trail — for anything you need to keep, read the transaction feed or store the webhook deliveries.
For the complete list of codes and what each one means, see Errors & rate limits.
← Run a test buySet up webhooks →