Filtering and pagination
GET /api/v1/opportunities takes filters as query parameters and returns one
page plus a cursor. The filters worth knowing first:
statusis repeatable. One ofscored,screened,notified,draft_requested,draft_sent,approved, orarchived.min_scoretakes a number in 0–100.deadline_beforeanddeadline_aftertake ISO 8601 date-times that combine into a window.sortacceptsscore(the default),deadline, ordiscovered_at.
There is one combination the API rejects: status=archived cannot be sent
alongside any other status. Archived is its own view, not a filter that stacks,
and sending both returns 400 validation_failed.
The response’s source_status describes the notice’s source lifecycle, not
your workflow. It is separate from the status filter above; check it before
acting on an opportunity. See source status and historical scores.
Paging
Section titled “Paging”limit accepts 1–100 and defaults to 25. Bigger pages mean fewer requests
against the same rate-limit budget, so prefer 100 for a bulk read.
curl "https://app.prokure.ca/api/v1/opportunities?limit=100&cursor=$NEXT_CURSOR" \ -H "Authorization: Bearer $PROKURE_API_KEY"nextCursor is opaque. Pass it back verbatim as cursor and stop when it comes
back null. Do not decode it, construct one, or assume anything about its
contents. The encoding is an implementation detail and offsets are not
supported. Keep the filters and the sort identical for every request in a paging
pass.
Related
Section titled “Related”- Getting started: the full parameter table.
- Best practices: a complete paging loop in TypeScript and Python.
- List opportunities.