P_declaredStockRequests

Returns a paginated list of your "Declared Stock" requests for a given time range, one entry per order. Each entry carries the reservation request together with the provision and cancellation requests for the same order, so you can reconcile a period without querying order by order.

Use P_declaredStockResult when you need the callback bodies, response codes and failure reasons for a single order — this query reports request statuses only and never returns callback payloads.

Supported arguments

The following arguments are supported by P_declaredStockRequests query:

FieldTypeDescription
afterString
firstInt
dateFromP_DateTime!Only return requests whose reservation was created after this moment
dateToP_DateTime!Only return requests whose reservation was created at or before this moment

Return type

The query returns the P_API_DeclaredStockRequestConnection type.

Date range

dateFrom and dateTo are both required and filter on the time the reservation request was created.

  • dateFrom is exclusive — a reservation created at exactly dateFrom is not returned.
  • dateTo is inclusive — a reservation created at exactly dateTo is returned.
  • The two may be at most 31 days apart. A wider range is rejected with an error.

Only the reservation's creation time is considered. An order whose reservation falls inside the range is returned in full, even when its provision or cancellation happened after dateTo.

Pagination

This query uses cursor-based pagination following the Relay Connection spec.

  • Use first to set the page size. The default is 20 and the maximum is 50000; larger values are clamped to the maximum rather than rejected.
  • On the first request, omit after (or pass null).
  • The response includes a pageInfo object:
    • hasNextPagetrue if more results exist beyond the current page.
    • endCursor — an opaque string representing the position of the last entry on the current page.
  • To fetch the next page, pass the previous response's pageInfo.endCursor as the after argument.
  • Repeat until pageInfo.hasNextPage is false.

Two things differ from other paginated queries in this API:

  • There is no totalCount. Page through until hasNextPage is false to count a period.
  • Only forward pagination is supported. hasPreviousPage and startCursor are present because the Relay spec requires them, but hasPreviousPage is always false — do not use it to decide whether earlier pages exist.

Treat cursors as opaque and pass them back unchanged. Their format is not part of the API contract and may change without notice. Keep dateFrom and dateTo identical across every request of a walk; a cursor is only meaningful within the range it was issued for.

Behavior

  • Results are ordered oldest reservation first, and that order is stable across pages.
  • Entries are scoped to your own merchant account.
  • reservation is always present — it is the entry's anchor.
  • provision is null until the order is paid for, and stays null for orders that were never provisioned.
  • cancellation is null unless the order was cancelled. It reports the order cancellation only; individual key returns are not included and never appear here.
  • originalOrderId is set only when the order was created by a retried order
  • createdAt may be null on very old records.

Example usage

Query

query getDeclaredStockRequests(
  $dateFrom: P_DateTime!
  $dateTo: P_DateTime!
  $first: Int
  $after: String
) {
  P_declaredStockRequests(
    dateFrom: $dateFrom
    dateTo: $dateTo
    first: $first
    after: $after
  ) {
    edges {
      cursor
      node {
        orderId
        originalOrderId
        reservation {
          status
          createdAt
          wholesale
        }
        provision {
          status
          createdAt
        }
        cancellation {
          status
          createdAt
        }
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

First page

Variables

{
  "dateFrom": "2026-07-01T00:00:00+00:00",
  "dateTo": "2026-07-31T23:59:59+00:00",
  "first": 2
}

Response

{
  "data": {
    "P_declaredStockRequests": {
      "edges": [
        {
          "cursor": "EfF1JN12gwCAAAAAAAAAAA==",
          "node": {
            "orderId": "e7f93c26-4a2d-11ed-90aa-4ae14ace4c13",
            "originalOrderId": null,
            "reservation": {
              "status": "COMPLETED",
              "createdAt": "2026-07-01T08:14:22+00:00",
              "wholesale": false
            },
            "provision": {
              "status": "COMPLETED",
              "createdAt": "2026-07-01T08:14:25+00:00"
            },
            "cancellation": null
          }
        },
        {
          "cursor": "EfF1K51mzoCAAAAAAAAAAA==",
          "node": {
            "orderId": "b13629bb-557f-1237-a6e5-5b42bf46b7e1",
            "originalOrderId": null,
            "reservation": {
              "status": "COMPLETED",
              "createdAt": "2026-07-01T09:02:41+00:00",
              "wholesale": false
            },
            "provision": {
              "status": "FAILED",
              "createdAt": "2026-07-01T09:02:44+00:00"
            },
            "cancellation": {
              "status": "COMPLETED",
              "createdAt": "2026-07-01T09:07:12+00:00"
            }
          }
        }
      ],
      "pageInfo": {
        "hasNextPage": true,
        "endCursor": "EfF1K51mzoCAAAAAAAAAAA=="
      }
    }
  }
}

The second entry shows an order whose provision failed and was then cancelled — the reservation succeeded, the provision ended in FAILED, and a cancellation request followed.

Next page

Pass the endCursor from the previous response as after, keeping dateFrom and dateTo unchanged.

Variables

{
  "dateFrom": "2026-07-01T00:00:00+00:00",
  "dateTo": "2026-07-31T23:59:59+00:00",
  "first": 2,
  "after": "EfF1K51mzoCAAAAAAAAAAA=="
}

Response

{
  "data": {
    "P_declaredStockRequests": {
      "edges": [
        {
          "cursor": "EfF2C74GVYCAAAAAAAAAAA==",
          "node": {
            "orderId": "7c642706-106c-17ec-aea9-b6c9510feba7",
            "originalOrderId": "e7f93c26-4a2d-11ed-90aa-4ae14ace4c13",
            "reservation": {
              "status": "COMPLETED",
              "createdAt": "2026-07-02T11:47:03+00:00",
              "wholesale": true
            },
            "provision": null,
            "cancellation": null
          }
        }
      ],
      "pageInfo": {
        "hasNextPage": false,
        "endCursor": "EfF2C74GVYCAAAAAAAAAAA=="
      }
    }
  }
}

hasNextPage is false, so this is the last page of the range. This entry has an originalOrderId, meaning the order came from a key replacement, and its provision is still null because the order has not been paid for yet.

Walking a longer period

Because a single request covers at most 31 days, split a longer period into month-sized ranges and paginate each one to completion before moving to the next:

{ "dateFrom": "2026-05-31T23:59:59+00:00", "dateTo": "2026-06-30T23:59:59+00:00", "first": 1000 }
{ "dateFrom": "2026-06-30T23:59:59+00:00", "dateTo": "2026-07-31T23:59:59+00:00", "first": 1000 }

Setting each range's dateFrom to the previous range's dateTo leaves no gap and no overlap, because dateFrom is exclusive and dateTo is inclusive.

Copyright 2026 Eneba. All Rights Reserved. JSC “Helis play”, Gyneju St. 4-333, Vilnius, the Republic of Lithuania