Standardized ActionKit pagination parameters
We are standardizing pagination across ActionKit so developers and agents can use one consistent pagination pattern across list and search actions, regardless of whether the underlying provider uses cursors, page numbers, offsets, or skip tokens.Affected API:What’s changing:Pagination input parameters:-
Paginated ActionKit actions will support
paginationParameters.pageCursoras the standard way to request the next page of results. Treat this value as an opaque string, even when the underlying integration uses a numeric page number or offset. -
Actions that support page sizing will support
paginationParameters.limitas the standard page size parameter.
Existing pagination input parameter names will remain supportedIf your application already passes action-specific pagination input keys (such as
page, pageNo, and pageNumber), those requests will continue to work.For new implementations, we recommend using paginationParameters.pageCursor and, when supported, paginationParameters.limit.- Paginated responses will standardize on
nextPageCursoras a string when another page is available, andnullwhen there are no more pages.
Breaking changeActions that previously returned
false or "" for nextPageCursor at the end of pagination will now return null.What do I need to do?
Handle the breaking change in response parameters:- If you currently check for
nextPageCursor === falseornextPageCursor === ""to detect the end of pagination, update that logic to handlenextPageCursor === null.
- For all ActionKit pagination code, pass the returned
nextPageCursorvalue intopaginationParameters.pageCursoron the next request. - Treat
nextPageCursoras an opaque string. Avoid parsing it as a number or calculating the next page value in your application code.
When will these changes be released?
- Changes to set
nextPageCursorasnullwill begin on July 31, 2026 and will gradually roll out across all ActionKit integrations. Updates will be propagated to the Tool-specific docs in the ActionKit Integration Reference. - We recommend updating your application code to handle
nextPageCursor === null(or falsey values) as a possible condition for the end of pagination during this transition period.
Custom Integration identifiers are now immutable
Before this change, changing the display name of a Custom Integration would result in a change in the integration identifier/slug (used inparagon.connect) and the Paragraph source path (after a para pull). For example, changing “TaskLab” to “Apex Tasks” would result in a change from custom.tasklab to custom.apextasks.This identifier is now immutable and set at the time your Custom Integration is created. For existing Custom Integrations, the identifier will be set immutably to the same value it currently has in your project.Existing Custom Integration identifiers are preservedAny hard-coded references you may use to existing Custom Integration identifiers will continue to work as expected, since the identifier has been set immutably to its current value. Any future changes to the display name will no longer impact this identifier.
What do I need to do?
-
Treat the
slugreturned by the API as the source of truth for Custom Integrations. If your application already uses theslugreturned by the API as the source of truth for identifiers, no changes are required. -
Replace any logic in your application that may derive Custom Integration identifiers from the display name with the
slugproperty provided by the API. A published Custom Integration’s identifier will no longer change when its display name changes. -
Upgrade the
@useparagon/connectSDK to v2.3.1 or later.@useparagon/connectSDK versions < 2.3.1 (which derive the identifier from the integration name) will continue to use name-derived identifiers and work without issue. You can upgrade to v2.3.1 or later to use the current, immutable identifiers.
-
Upgrade
@useparagon/paragraphto v1.1.1 or later.
When were these changes released?
- These changes were released on April 2, 2026. Platform versions of >=
v2026.0402will include this update.
Updates to GET /sdk/integrations and Proxy API
To improve the ergonomics of the API, we are introducing a few changes to the GET/projects/:projectId/sdk/integrations and Proxy API endpoints for Custom Integrations.We are also removing some unnecessary fields from the response of the GET /projects/:projectId/sdk/integrations endpoint to improve performance. Please review these changes to ensure that your application is not using any of the fields scheduled for removal.Affected endpoints:- GET
/projects/:projectId/sdk/integrations - Proxy API
-
In GET
/projects/:projectId/sdk/integrations, thetypefield of Custom Integrations will now be the full slug that is used inparagon.connectcalls. -
In GET
/projects/:projectId/sdk/integrations, some unnecessary fields are being removed from Integrations:- To optimize the performance of this endpoint, some fields of Integrations are being removed. Please ensure that the following fields are not in use by your application:
integration.dateCreatedintegration.dateUpdatedintegration.resourceIdintegration.configs[].dateCreatedintegration.configs[].dateUpdatedintegration.configs[].integrationIdintegration.workflows[].dateCreatedintegration.workflows[].dateUpdatedintegration.workflows[].teamIdintegration.workflows[].isOnboardingWorkflowintegration.workflows[].workflowVersionintegration.customIntegration.dateCreatedintegration.customIntegration.dateUpdatedintegration.customIntegration.projectIdintegration.customIntegration.oauthScopesintegration.customIntegration.oauthIncludeClientAuthorizationHeaderintegration.customIntegration.usePKCEInCodeExchangeintegration.customIntegration.apiBaseUrlintegration.customIntegration.testEndpointPathintegration.customIntegration.isTestEndpointVerifiedintegration.customIntegration.apiAuthorizationintegration.customIntegration.userProfileConfig
- To optimize the performance of this endpoint, some fields of Integrations are being removed. Please ensure that the following fields are not in use by your application:
- Proxy API now supports using the
custom.nameformat when sending Proxy requests for Custom Integrations-
Instead of passing in a
customIntegrationId, you will now be able to pass incustom.name(the same slug used forparagon.connect) directly to the Proxy API. -
Example:
-
Instead of passing in a
What do I need to do?
- Verify that your use of
integrations.typefor Custom Integrations does not rely on the value being exactly"custom". The newtypefield will include the full slug value, e.g.custom.integrationName. - Verify that you are not using any of the fields scheduled for removal from the API.
When were these changes released?
- These changes were released on July 7, 2025.