API and system limits

Limits are in place to protect Atomic from traffic spikes, and processing demands that could degrade performance. The specific limits vary depending on the Service Tier used by your Zone. Contact your Customer Success Lead for limits specific to your Zone.

Card operations

A card operation is a unit of processing within the Atomic service. A card operation is any action which creates or updates a card, or updates card state. Read operations, such as polling for or WebSockets pushing for feed updates, are not considered a card operation.

Card operations can originate from three sources:

1. Action Flow API - Customer systems send requests to the Action Flow API which result in card operations, e.g. to create new cards, update cards, change card status. These are called Requested Card Operations.
2. Atomic System Events — Atomic is processing a scheduled action relating to a card, which result in card operations. E.g. un-snoozing or expiring
3. Client API — Customers have interacted with a card which results in card operations. E.g. dismissing, completing, snoozing.

Action Flow API request limits

The Action Flow API is used to send card operation requests to Atomic for processing.

Action Flow API limits

Additional limits to the Action Flow API will be implemented soon.

There is currently one limit to the Action Flow API. When starting an Action Flow via the /start or /test endpoints and targeting by either tags, segment or a filter (bulk target), not by userId or allTestUsers, the Atomic system queues a task to process the request. Only 5 of these queued tasks can be running at any given time. Therefore the API will return an HTTP 429 status code and not process the request when:

• An invocation payload contains more than 5 flows targeting by bulk target criteria.
• There are already some bulk target tasks running and the request would cause there to be more than 5 running.
  • For example; 3 bulk target tasks were started and another 3 were then immediately requested. The second request would be rejected.

Queue priority

Internally, Card Operation requests are prioritized according to origin. Operations initiated by Client API/Customer interaction are processed first, followed by Internal System Events and lastly the Action Flow API. This ensures customers actions are the least exposed to congestion.