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:
| Field | Type | Description |
|---|---|---|
after | String | |
first | Int | |
dateFrom | P_DateTime! | Only return requests whose reservation was created after this moment |
dateTo | P_DateTime! | Only return requests whose reservation was created at or before this moment |
Return type
The query returns theP_API_DeclaredStockRequestConnection type.
Date range
dateFrom and dateTo are both required and filter on the time the reservation request was
created.
dateFromis exclusive — a reservation created at exactlydateFromis not returned.dateTois inclusive — a reservation created at exactlydateTois 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
firstto set the page size. The default is20and the maximum is50000; larger values are clamped to the maximum rather than rejected. - On the first request, omit
after(or passnull). - The response includes a
pageInfoobject:hasNextPage—trueif 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.endCursoras theafterargument. - Repeat until
pageInfo.hasNextPageisfalse.
Two things differ from other paginated queries in this API:
- There is no
totalCount. Page through untilhasNextPageisfalseto count a period. - Only forward pagination is supported.
hasPreviousPageandstartCursorare present because the Relay spec requires them, buthasPreviousPageis alwaysfalse— 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.
reservationis always present — it is the entry's anchor.provisionisnulluntil the order is paid for, and staysnullfor orders that were never provisioned.cancellationisnullunless the order was cancelled. It reports the order cancellation only; individual key returns are not included and never appear here.originalOrderIdis set only when the order was created by a retried ordercreatedAtmay benullon 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.