Read filtered API results

Use the API reference for each endpoint's current request and response. The examples below show request bodies for Steam / ListAccounts. They are examples, not live account or health data.

Start with active accounts

Create a workspace API key with the policies your integration needs. Send JSON by POST to https://api.goldmine.to/steam.v1.Steam/ListAccounts, with Content-Type: application/json and Authorization: Bearer <your-api-key>.

{
    "limit": 50,
    "filter": {
        "deleted": false,
        "query": "trader"
    },
    "statuses": ["SESSION_STATUS_LOGGED_ON"],
    "sortField": "ACCOUNT_SORT_FIELD_ACCOUNT_NAME",
    "descending": false
}

filter.query is a literal, case-insensitive account-name search. It is applied before pagination. Send filter.deleted: false for the active account set: omitting this field includes both active and soft-deleted accounts. Omit statuses, or send an empty array, to include every session status.

A logged-on session describes the account's connection. It does not establish inventory freshness, market readiness or permission to execute trades.

Read the response envelope

The successful response contains accounts, an array of full account records, and nextCursor. Render the returned accounts directly; do not treat them as account names requiring a second lookup. An empty accounts array is a successful empty result, not a read failure.

Other list endpoints have their own envelope. For example, Contracts / ListInventoryItems returns full records in inventoryItems. Check the endpoint schema rather than assuming every response uses items, ids or accountNames.

Continue with the same request

If nextCursor is nonempty, send it as cursor in the next request, preserving the workspace, filters, statuses, sort and direction:

{
    "limit": 50,
    "filter": {
        "deleted": false,
        "query": "trader"
    },
    "statuses": ["SESSION_STATUS_LOGGED_ON"],
    "sortField": "ACCOUNT_SORT_FIELD_ACCOUNT_NAME",
    "descending": false,
    "cursor": "<nextCursor from the previous response>"
}

Copy the actual returned cursor. Treat it as opaque: do not decode it, construct one or reuse it for another workspace or query. Stop when nextCursor is empty or absent. Changing the query, status selection or ordering starts a new page walk with an empty cursor.

Recover a read without skipping a page

If a transient read fails, retain the last successful page and retry the failed request with the same inputs and cursor. Advance the cursor only after receiving a successful page. Use capped exponential backoff with jitter and respect server retry guidance; do not start an immediate retry loop.

An invalid_argument response can indicate malformed inputs or an obsolete cursor. Check the error before restarting the page walk with an empty cursor. Authentication and permission failures need the appropriate key or policies; repeatedly sending the same rejected request will not repair them.

This guidance concerns reads. An uncertain create, update or execution result needs its own reconciliation; do not replay a mutation because a list request can be retried.