The offset/pagination suggestions in the replies above are for listing access profiles via the API, but I don’t think that’s your actual problem. You are trying to link access profiles to the application (source app), and the UI caps out at 250, right? If so, try to use the API to add the remaining 273 directly.
The endpoint you want is:
PATCH /beta/source-apps/{sourceAppId}
Content-Type: application/json-patch+json
X-SailPoint-Experimental: true
With a body like this:
[
{ "op": "add", "path": "/accessProfiles/-", "value": "<access-profile-id>" }
]
The /- appends to the existing list, so it won’t overwrite the APs you’ve already linked. You can also batch multiple adds in one call:
[
{ "op": "add", "path": "/accessProfiles/-", "value": "<ap-id-1>" },
{ "op": "add", "path": "/accessProfiles/-", "value": "<ap-id-2>" },
{ "op": "add", "path": "/accessProfiles/-", "value": "<ap-id-3>" }
]
You said you got a 404 error when you tried to use an API call. I think that was probably because the ID you used was the source ID, not the source app ID. Those are different. To find the right one, use the /all endpoint, which returns every source app in the org:
GET /beta/source-apps/all?filters=name eq "YourAppName"
X-SailPoint-Experimental: true
Then use the id from that response in your PATCH call.
As Ousmane N’DIAYE mentioned, there is also a newer v1 version of this endpoint (PATCH /source-apps/v1/{id}) If you want to use that instead, same behavior, also experimental.
For 273 APs, just script a loop through your AP IDs and fire the patch calls. This thread has a working Python SDK example if that helps.
And yeah, skip the /cc/ route. That is deprecated and not something you want to rely on going forward.