Browse all endpoints available in this API specification.
The Workflow Canvas Service API for browsing workflows, manually triggering workflow versions, and viewing run history.
Pagination and rate limiting
This API uses pagination and rate-limiting controls to ensure consistent performance and reliable access to data. Instead of returning all records in a single response, results are delivered in smaller, manageable pages. This approach reduces server load, improves response times, and helps client applications process data safely without consuming excessive memory.
Pagination also plays a role in rate limiting by distributing requests more evenly. By avoiding large or frequent data pulls, the API minimizes the risk of performance degradation or throttling.
How pagination works
Pagination is implemented using an offset-based model controlled through query parameters:
page: Specifies which page of results to retrieve (1-based index).limit: Specifies the number of items returned per page.
By default, each request returns 25 items, and the maximum allowed page size is 500 items. These limits ensure predictable performance while still allowing flexibility for different use cases.
Each paginated response includes metadata such as currentPage, totalPages, totalItems, and pageSize, which enables clients to navigate through the dataset efficiently.
Retrieve complete datasets
To retrieve all available data from a paginated endpoint, requests must be made iteratively. Start with page=1, then use the pagination metadata in each response to determine whether additional pages exist. Continue incrementing the page value until all pages have been retrieved, and combine the results into a single dataset.
allResults = []
page = 1
while page exists:
response = GET /endpoint?page={page}&limit=500
allResults += response.data
if page == response.totalPages:
break
page = page + 1This approach ensures complete data retrieval without relying on guesswork or inefficient request patterns.
Rate limit considerations
Because pagination directly affects request patterns, it also helps prevent excessive load on the API. To avoid throttling or blocked requests:
- Use reasonable page sizes (typically between 25 and 500).
- Reduce the total number of requests by selecting a higher limit when retrieving large datasets.
- Space out requests slightly to avoid burst traffic.
- Monitor responses for rate-limit signals (such as HTTP 429 errors).
If rate limits are reached, implement exponential backoff by waiting before retrying requests and increasing the delay between retries.
Best practices
To ensure consistent and efficient use of pagination:
- Always use
pagevalues greater than or equal to 1. - Always use
limitvalues between 1 and 500. - Use larger page sizes when retrieving full datasets to minimize API calls.
- Cache previously retrieved data to avoid redundant requests.
- Limit concurrent requests to prevent overwhelming the service.
Request and service availability
Rate limit behavior and constraints are documented by available contract details in this specification. The specification documents the following service availability related statuses.
| Status | Description |
|---|---|
| 500 | Internal Server Error |