Homepage 5 API Documentation 5 How Action1 API Works

How Action1 API Works

Action1 enables you to automate your tasks and build integrations with a help of an API (application programming interface). Action1 API is REST-based and provides access to app resources through special endpoints. Action1 leverages standard HTTP verbs and JSON-based request bodies.

  • GET – retrieving resources
  • POST – creating new resources
  • PATCH – updating and modifying resources
  • DELETE – removing resources

What Can You Do with Action1 API?

  • List your organizations
  • List endpoints
  • Retrieve endpoint data
  • Retrieve information about users
  • Retrieve information about available app packages
  • Check outdated endpoints
  • Generate reports
  • and many more

For complete API specification, see this section. For general information about Action1, see Getting Started with Action1.

NOTE: We recommend using PSAction1 PowerShell module for substantially simplified API scripting experience.

Action1 API Requests and Rate Limits

To help ensure Action1 platform stability, reliability, fair resource usage, and consistent performance for all customers, dynamic API rate limits have been recently introduced.

  • If API requests are sent too frequently, the API may return an HTTP 429 – Too Many Requests response. This response indicates that API requests for your Action1 Enterprise have been temporarily rate-limited because the allowed request threshold was exceeded.
  • To reduce the likelihood of receiving a Too Many Requests response, Action1 recommends keeping request rates below 30 requests per minute per Action1 Enterprise.

NOTE: Requests across all API endpoints, including data sources, users, organizations, etc., are counted.

Action1 also strongly recommends implementing retry logic for these 429 – Too Many Requests responses:

  1. If the server returns a 429 response, wait 1 second before retrying the request.
  2. If the retry request also returns a 429 response, wait 1 minute before retrying again.
  3. After that, continue sending requests at a lower frequency to avoid repeated rate limiting.

Implementing this retry logic helps integrations adapt to dynamic rate limiting and reduces the likelihood of repeated temporary restrictions on API requests.