# Paginate And Authenticate Oracle Fusion REST API Calls Correctly > Source: https://netray.co/erp-help/fusion-rest-api-pagination-and-authentication > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Oracle Fusion Cloud REST APIs authenticate with HTTP Basic Authentication, an integration user's credentials, over HTTPS by default, and paginate with limit and offset query parameters rather than a page number. Loop on the hasMore flag in the response until it returns false to retrieve a full result set. ## Kind how-to ## System oracle-fusion ## Erp Oracle Fusion Cloud ERP ## Module Fusion REST APIs / Integration ## Query How to paginate and authenticate Oracle Fusion REST API calls ## Alternate Queries - Oracle Fusion REST API limit offset pagination - Oracle Fusion REST API basic auth - Fusion REST API hasMore totalResults - Oracle ERP Cloud REST API authentication ## Applies To Oracle Fusion Cloud ERP REST APIs (fscmRestApi), all current API versions ## Steps ### Call and paginate a Fusion REST resource correctly **Items:** - Create 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. - Build the request against the resource URL and send the Authorization header as Basic base64(username:password) over HTTPS. - Add onlyData=true to strip HATEOAS link noise from the payload if you only need the data attributes. - Add 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. - Read the hasMore field in the response body; if true, increment offset by your limit and repeat the call. - Use totalResults=true only when you need an exact count, since computing it adds overhead to every call - avoid it on high-frequency polling. - Prefer a q= filter or a finder to narrow results server-side instead of pulling every row and filtering client-side. - Check the response's links array for an entry with rel next as an alternative to manually tracking offset yourself. ## Sections ### Why The Default Page Looks Incomplete **Body:** Integrations commonly lose records because the default limit, often 25, silently caps the response and the caller never checks hasMore. The API is not failing - it returned exactly what was asked for. Always check hasMore and loop rather than assuming a single call returns everything. **Code:** - GET /fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=100&offset=0&onlyData=true - Authorization: Basic base64(username:password) ### Authentication Options **Body:** HTTP Basic Authentication over HTTPS with a dedicated integration user is the default and most common pattern for Fusion ERP REST APIs. Some tenants also support federated SSO or OAuth-based flows depending on how Identity Cloud or OCI IAM is configured, but Basic Auth against a tightly scoped integration user remains the simplest, most widely used setup for server-to-server integrations. ### Security Roles Behind The API **Body:** The integration user needs both function security, a role that includes the REST resource's function privilege, and data security, a data role or security profile scoping which business units, ledgers, or cost organizations the user can see. A 403 response, or an empty result set with no error, is frequently a data security scope problem, not a broken query. ### Filtering With q= And Finders **Body:** The q parameter accepts a query expression, such as a status equality filter, to filter server-side; finders are prebuilt, named queries some resources expose for common lookups. Both reduce payload size and the number of calls compared to pulling every record and filtering in your integration code. ## 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. ## Ai Angle For integration troubleshooting, ERPray can inspect an actual failed or truncated REST call against your Fusion tenant - the URL, headers, and response - and tell you directly whether it is a pagination gap, a missing data role, or a malformed q filter, instead of you working through the REST API guide error code by error code. ## Faq ### What does hasMore actually mean? **Answer:** It is a boolean in the response body indicating whether more records exist beyond the current page given your limit and offset. Treat it as the loop condition: keep calling with an incremented offset while hasMore is true, and stop once it returns false. ### Does Oracle Fusion REST API support OAuth? **Answer:** Some Fusion environments support OAuth or SSO-based authentication depending on how Identity Cloud or OCI IAM is configured for the tenant, but HTTP Basic Authentication with a dedicated integration user remains the standard, most commonly documented pattern for server-to-server REST integrations against Fusion ERP. ### Why do I get 403 even though my credentials are correct? **Answer:** Correct credentials only satisfy authentication. The integration user also needs a role with function security for that REST resource and a data role or security profile granting access to the specific business unit, ledger, or other scoped data you are requesting - missing either produces an access error even with valid login credentials. ### How large can I set limit? **Answer:** Oracle enforces a maximum page size per resource; requesting more than the maximum typically gets capped rather than rejected. For large extracts, it is usually more reliable to page in moderate batches, for example 100 to 500 rows, than to push for one enormous response. ## Search terms Oracle Fusion REST API pagination, Fusion REST API limit offset, Oracle Fusion REST API authentication, hasMore totalResults Fusion API, fscmRestApi basic auth, Oracle ERP Cloud REST API integration, Oracle Fusion REST API 403 error, Fusion REST API data security role --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json