Paginate And Authenticate Oracle Fusion REST API Calls Correctly

Call and paginate a Fusion REST resource correctly

1. 1Create or reuse an integration user with a job or duty role that grants REST API access and the data security needed for the resource you are calling.
2. 2Build the request against the resource URL and send the Authorization header as Basic base64(username:password) over HTTPS.
3. 3Add onlyData=true to strip HATEOAS link noise from the payload if you only need the data attributes.
4. 4Add limit and offset to control page size, starting with offset=0; the default limit is commonly 25 if you omit it, which silently truncates larger result sets.
5. 5Read the hasMore field in the response body; if true, increment offset by your limit and repeat the call.
6. 6Use totalResults=true only when you need an exact count, since computing it adds overhead to every call - avoid it on high-frequency polling.
7. 7Prefer a q= filter or a finder to narrow results server-side instead of pulling every row and filtering client-side.
8. 8Check the response's links array for an entry with rel next as an alternative to manually tracking offset yourself.

Authentication Options

Filtering With q= And Finders

Common pitfalls

• !Hardcoding a single call with no pagination loop, so only the first page, often 25 rows, ever gets processed.
• !Reusing a personal user's credentials for integrations instead of a dedicated integration user, which breaks when that person's password rotates or access changes.
• !Requesting totalResults=true on every polling call, adding unnecessary load for a count you do not actually need each time.
• !Assuming a 200 response with zero rows means no data exists, when it can also mean the data security profile hides those rows from the integration user.
• !Not URL-encoding the q= filter expression, causing the query to silently fail or return unexpected results.
• !Polling too frequently without checking rate limiting guidance, which can throttle or block the integration user.