How Action1 API Works

The Action1 API enables you to automate tasks and build integrations with Action1.
The API follows the REST architecture and provides access to Action1 resources through dedicated endpoints. Requests and responses use JSON, and operations are performed using standard HTTP methods:

• GET – retrieve resources
• POST – create resources
• PATCH – update and modify resources
• DELETE – remove resources

What You Can Do with Action1 API

• List your organizations
• List endpoints
• Retrieve endpoint data
• Retrieve information about users
• Retrieve information about available app packages
• Identify endpoints with missing updates
• Generate reports
• and many more

Action1 API Requests and Rate Limits

To maintain platform stability, reliability, fair resource usage, and consistent performance for all customers, Action1 applies dynamic API rate limits.

• If API requests are sent too frequently, the API may return an HTTP 429 – Too Many Requests response.
• To reduce the likelihood of receiving a 429 response, Action1 recommends keeping request rates below 30 requests per minute per Action1 Enterprise.

Response Structure

The following example shows an HTTP 429 response:

{ 
    "id":"0", 
    "type":"Error", 
    "status":429, 
    "developer_message":"Request rate limit exceeded. Please try again in 30 seconds.", 
    "user_message":"Request rate limit exceeded. Please try again in 30 seconds.", 
    "details":{ 
        "retry_after":30 
    } 
}

• The Error type and 429 status indicate that API requests for the Action1 Enterprise have been temporarily rate-limited.
• The retry_after parameter specifies how many seconds the integration should wait before retrying the request. In this example, the recommended delay is 30 seconds.

Handling HTTP 429 Responses

Action1 recommends implementing retry logic for such 429 – Too Many Requests responses, considering the following:

• Read the retry_after value returned in the response. This value specifies how many seconds to wait before retrying the request.
• Wait for the specified number of seconds, then retry the request. If the retry_after value is missing or invalid, you can apply a fallback delay of your own.
• To avoid repeated rate limiting, continue subsequent requests at a lower frequency.

This approach helps integrations adapt to dynamic rate limiting and reduces the likelihood of repeated temporary restrictions.
Implementation examples in PowerShell, Python, and JavaScript are described below.

Examples

Understanding the Retry Logic

The examples  (in PowerShell, Python,  and JavaScript ) show how the key aspects of the retry logic can be implemented.

Each example script does the following:

1. Sends a GET API request. If successful, proceeds with the response.
2. If the server returns HTTP 429, the script reads the retry_after value and waits for that many seconds (30) before retrying the request.
   If retry_after is missing or invalid, the script applies an exponential fallback delay of 2, 4, or 8 seconds.

3. Before each retry, the script compares the retry counter (retry429Count) with the configured maximum (max429retries). The example scripts will stop retrying after three attempts.
4. Each example script stops immediately for any error other than HTTP 429.
   In addition, the Python script specifies the explicit 60-sec request timeout so that the request should not wait indefinitely for the server.

Advanced Examples

The advanced example scripts organize the same retry logic into reusable functions and add validation and debug logging.

Each advanced example:

• Uses the API-provided retry_after value when available.
• Applies exponential backoff when retry_after is missing or invalid.
• Reports the original error if the server returns an HTTP status code other than 429.
• Stops with a retry-limit error when the maximum number of retries has been reached.