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 Atomic tenant. 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:
- 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.
- Atomic System Events: Atomic is processing a scheduled action relating to a card, which result in card operations. E.g. un-snoozing or expiring
- Client API: Customers have interacted with a card which results in card operations. E.g. dismissing, completing, snoozing.
Action Flow API request limits
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.
Content character limits
When authoring cards and Action Flows in the Workbench, fields have maximum lengths. These guard against large inputs degrading performance.
These limits apply to the content you author in the Workbench. They do not apply to variable values resolved at runtime. Content supplied through the Action Flow API or resolved from a request payload is not subject to these limits.
Character length is counted by displayed character (an emoji counts as one), and a %{variable} placeholder counts as the length of its token, not the length of its resolved value.
These limits are designed to be generous. They are to stop abuse of the system, not to limit your Action Flow and card creation. Get in contact with support if you require changes to any limits.
Card elements
| Field | Limit |
|---|---|
| Headline | 200 |
| Text block | 4,000 |
| Text block expand / collapse labels | 100 |
| Category title | 100 |
| Element labels (text input, number input, dropdown, date picker, file upload, stepper, switch) | 100 |
| Input placeholders (text input, number input, dropdown, date picker, file upload) | 100 |
| Text input / dropdown default value | 100 |
| Button text | 100 |
| Button / link URL | 2,000 |
| Checkbox label / value | 100 |
| Image, video, icon and thumbnail alt text | 250 |
| Image / thumbnail source URL | 2,000 |
| Validation error message | 200 |
| Validation regular expression | 200 |
| Subview title | 100 |
Variables
| Field | Limit |
|---|---|
| String variable default value | 2,000 |
| List / checkbox-list variable default value (total across all items) | 2,000 |
Numbers
A number input's default value, number variable defaults, and numeric validation thresholds (such as minimum and maximum) are limited by a max value rather than character count.
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.