Monitoring a paginated GraphQL API: every auction listing, on every check

The problem

A domain investor came to us wanting an alert whenever a domain was added to or removed from a marketplace's .ai auction list. The list had over 6,000 listings.

A normal page monitor only saw the first 100 rows. The data behind the table came from a GraphQL API, but that API:

only accepts POST requests with a JSON body, and Verid monitors could only send GET
returns at most 1,000 items per page, so the full list needs several requests

They asked us for a monitor on that API that gets every entry, with no page size limit.

What we added

Every monitor now has a Request section under Advanced options:

Method and body. Send POST, PUT or PATCH with any request body, such as a GraphQL query.
Pagination. Verid fetches every page and joins all the items into one list before your fields are read. It works with page numbers or offsets, cursors, next-page URLs, and Link headers.

For this customer, one check now makes 7 requests, joins 6,116 listings, and takes about 5 seconds.

How to use it

1. Copy the request from your browser

Open the page, press F12, go to the Network tab and reload. Click the request that returns the list, then copy its URL and body from Payload. In Response, note where the list of items is and where the total count is.

2. Create the monitor

Field	Example
URL	the API URL you copied
What to monitor	A specific value, method JSONPath
Field	`names` = `$.data.collection.sales.items[*].product.name`
Alert me when	Specific field changes, field `names`

3. Fill in Advanced options > Request

Field	What it does	Example
Method	How the request is sent	`POST`
Body	Sent exactly as written. Use the largest page size the API allows	the copied body, `pageSize: 1000`
Follow pages and merge every item	Turns pagination on	on
How the API pages	How the API points to the next page	Page number or offset
Page value goes in	Where the page number goes: the URL or the JSON body	JSON body
Body path / Query parameter	The key in your request that holds the page number	`variables.page`
Items array path	Where the list is in the response. Empty if the response is a list	`data.collection.sales.items`
Total count path	Optional. Stops as soon as that many items are fetched	`data.collection.sales.total`
Has-more flag path	Optional. Stops when this is `false`	`has_more`
First value / Step	Page number of the first request, and how much it goes up	`1` / `1` (offsets: `0` / page size)
Max pages	Safety limit per check, up to 50	`20`

For cursor pagination, set Next cursor path (such as data.pageInfo.endCursor) instead of first value and step. For next-page URL, set Next URL path (such as next). A Link header needs no extra field.

4. Test, then save

Click Test against URL. The preview sends the same requests a real check does and shows a line like "Fetched 7 pages and merged 6116 items."

Good to know

Track only what matters. Watching whole items alerts on every bid change. Watching only the names alerts only when a listing is added or removed.
No partial data. A check fails if any page returns an error, a page has no list at the items path, a page repeats the one before it, or the page limit runs out with pages left. After 10 failed checks in a row, the monitor pauses and emails you.
Always direct. A monitor with a custom request is never sent through the browser or proxy, because a browser can only send GET.
Most common mistake: putting a response path in Body path. That field is the page key inside your own request body, such as variables.page.

The full field reference is in the API docs. Need something Verid cannot do yet? Tell us. This feature started as one customer's request.