Oracle Fusion REST API pagination controls how much of a collection one request returns. A successful first page can still omit most matching invoices or workers. Read the response's paging fields and follow the selected resource's documented behavior before treating an export as complete.
Use q to limit the business population before paging. A scoped invoice example is GET /fscmRestApi/resources/11.13.18.05/invoices?q=InvoiceNumber='DEMO-INV-1042'&limit=25&offset=0. The identifier is synthetic. Check that the field is queryable for that endpoint and encode parameter values with your HTTP client. Display labels and internal values are not interchangeable.
The requested limit is the page size and offset is the starting position. Read the actual values Oracle returns. The response's count describes the current page; it is not the total size of the business population. Continue according to hasMore and fail visibly if the response cannot be interpreted.
Choose a documented orderBy field that gives stable ordering, preferably with a unique tie-breaker. Oracle's collection guidance notes that records can move between pages when a collection changes during extraction. Ordering does not turn several live requests into a database snapshot. Record the extraction window and reconcile identifiers.
This Oracle-documented SQL example illustrates the same synthetic invoice filter with an explicit business unit and a stable invoice-ID order. It is a reporting query rather than a REST request. Replace both identifiers before running it in your test environment.
SELECT invoice_id,
invoice_num,
org_id,
COUNT(*) OVER () AS matching_rows
FROM ap_invoices_all
WHERE invoice_num = 'DEMO-INV-1042'
AND org_id = 300100000000001
ORDER BY invoice_id
OFFSET 0 ROWS FETCH NEXT 25 ROWS ONLY;Increase the offset by 25 for the next SQL page and keep the filter and ordering unchanged. MATCHING_ROWS counts the SQL population before pagination. REST access rules can produce a different population, and separate SQL executions do not share a snapshot automatically. Oracle documents the row-limiting clause in its SELECT reference.
Request only the fields the consumer needs. Keep resource links while resolving a child resource or a composite key. Remove them only when subsequent steps no longer depend on them. Expanding every child can increase the payload and still leave a child collection incomplete.
Page large child collections separately. An invoice collection and its attachment collection have independent result sets. A parent page containing twenty invoices says nothing about whether every attachment for each invoice was retrieved. Track the parent key and inspect the child's paging evidence.
Fusion Toolkit can handle supported limit-and-offset collections with fusion-toolkit --profile api-test oracle-cloud-rest-client --operation getWithHeaders --url "/fscmRestApi/resources/11.13.18.05/invoices?q=InvoiceNumber='DEMO-INV-1042'" --paginate --page-size 100 --resultFile output/invoices.json. Create the output directory first. Check the exit code and output before downstream processing. Safety limits and endpoint differences still matter.
Validate a test export using unique business identifiers and expected record counts. Do not silently remove repeated IDs without investigating why they appeared. For large scheduled extraction workloads, compare the alternatives in the Oracle Fusion extraction guide. This article was reviewed on 8 November 2026.
You can also use an LLM with the Fusion Toolkit AI Administrator skill and ask, "Find invoice DEMO-INV-1042 for this supplier and business unit, and tell me whether the result is complete." It can perform supported documented reads without requiring you to write filters or pagination requests. Name the environment and the records you need.