Skip to main content

API and system processing 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

Limits to the Action Flow API will be implemented soon.

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.