Cache Management in Unify Automations stores the output of a node or an API response so that subsequent runs can retrieve the cached result instead of re-executing the operation — reducing latency and the number of external API calls.
Overview
Cache Management in Unify Automations stores the output of a node or an API response so that subsequent runs can retrieve the cached result instead of re-executing the operation — reducing latency and the number of external API calls.
Caching is available in two contexts: in the Automation Builder, where individual nodes cache their output between runs, and in the API Manager, where a Cache Policy caches responses from an API endpoint. Both contexts share the same core concepts — a cache key, a time-to-live (TTL), and a policy for when to use the cached value — but are configured in different places.
Cache Management in Automation Builder
Configure caching on any node by opening the node's Cache settings section.
Field | Description |
|---|---|
Time-to-Live Period | How long the cached value is stored, in seconds. Maximum: 3600 seconds (1 hour) |
Fields to Cache On | The input field values that identify a unique cache entry (e.g., user_id, order_id). Two runs with different values for these fields produce separate cache entries |
Cache Usage Policy | When to use the cached value: Always (use cache whenever available) or On Error (use cache as a fallback when the node errors) |
Only Cache When | A condition that must be true for the result to be cached at all (e.g., only cache when status equals "success") |
Evict Cache | Clears the cache entry for a specific key without clearing everything |
Clear All Cache | Clears all cache entries for this node |
Cache Management in API Manager
API Manager cache is configured via the Cache Policy. Key differences from node-level caching:
The policy applies to an entire API Group or specific endpoints, not a single node.
Cache keys are based on request parameters (query params, headers, or request attributes).
One policy is reusable across multiple APIs.
Maximum TTL is also 3600 seconds (1 hour).
Clearing Cache
To clear cached data:
Per entry: Use the "Evict Cache" field in the node's cache settings, providing the key values that identify the entry to remove.
All entries: Use "Clear All Cache" to wipe all cached results for the node in one action.
Best Practices
Set the TTL based on how often the underlying data changes — data that updates every 5 minutes should have a TTL of 300 seconds or less; relatively static data (reference lists, configuration) can use the full 1-hour TTL.
Use specific, narrow cache keys (user_id, order_id) rather than broad ones — broad keys cause cache collisions where different inputs incorrectly share a cached result.
Monitor cache hit rates in run logs to confirm the cache is being used as intended.
Use "On Error" cache policy for critical nodes where stale data is acceptable in a failure scenario but no data at all would break the automation.
Notes
Caching reduces the number of external API calls your automations make and speeds up repeated runs for the same inputs. To make the most of it:
Start with a conservative TTL and extend it if the cache hit rate is low — a TTL that is too short negates the benefit; one that is too long serves stale data.
Use "Fields to Cache On" to scope the cache to the right granularity — missing a key dimension causes cache collisions.
Clear caches explicitly after a data import or bulk update, rather than waiting for TTLs to expire.
Prefer API Manager Cache Policy for caching inbound API responses; prefer node-level caching for expensive internal computations or upstream API calls inside an automation.
Properly configured caching can cut the run time and API call count of a high-volume automation by an order of magnitude.