Skip to main content

Troubleshooting

Use this page when API reads do not match what you expect. Most issues fall into one of four buckets: invalid request parameters, stale snapshots, using the wrong surface for the job, or expecting immediate read-after-write consistency.

400 Bad Request​

The current read endpoints validate several inputs and return 400 for bad parameters.

Common cases:

  • /orders and /positions require a valid account address.
  • /markets/tickers validates addresses and symbols filters.
  • /rates validates period and averageBy.
  • /apy and /performance/* validate period.

If you receive a 400, validate the exact query string before retrying. Retrying the same invalid input will not succeed.

A value looks stale​

Start by checking whether you are reading from a cached or indexed surface.

  • Use /markets/info when you need near-live market state.
  • Use /markets when a 60 second cache window is acceptable.
  • Use GraphQL for historical activity, not for the latest write-path state.
  • Use a single composite read where possible instead of stitching unrelated polls together.

If you need one coherent account snapshot, prefer one positions call with includeRelatedOrders: true over multiple loosely coordinated reads.

A write succeeded on-chain, but the API still does not show it​

That is usually a surface mismatch, not a broken API call.

  • Public API guides in this section describe read surfaces.
  • Writes belong to SDK v1 or direct contracts.
  • After a write, wait for the transaction receipt first, then poll the read surface you care about until the state appears.

Do not assume the first follow-up HTTP or GraphQL read will reflect final state. Submission, keeper execution, and indexing can complete at different times.

Positions and orders do not line up​

If your UI shows position state together with linked orders, fetch them from the same logical snapshot.

Recommended pattern:

import { GmxApiSdk } from "@gmx-io/sdk/v2";

const apiSdk = new GmxApiSdk({ chainId: 42161 });

const positions = await apiSdk.fetchPositionsInfo({
  address: "0x9f7198eb1b9Ccc0Eb7A07eD228d8FbC12963ea33",
  includeRelatedOrders: true,
});

Use a separate account-wide orders read only when you need a dedicated orders screen.

There is no documented public SLA​

The current manual docs do not publish a public SLA for these surfaces. Build your client as if network errors, timeouts, or stale snapshots can happen.

Recommended client behavior:

  1. Use endpoint-specific fallback URLs where they are documented.
  2. Add retries with backoff for safe read operations.
  3. Keep write confirmation logic separate from read polling logic.
  4. Log the exact surface you queried so you can distinguish API v1 REST, API v2, GraphQL, and SDK-backed reads during incident review.

Next steps​