Skip to content
APIANT
GuidePlatformv1

Data Storage

How automations keep state across runs — APIANT's built-in lookup-table storage and what it's for.

#automation#storage#state

A running automation finishes when the last action completes. State that needs to outlive a run has to live somewhere — APIANT gives every automation its own built-in lookup table for that.

You don't have to ask for it. Claude uses it automatically whenever a workflow you've described needs persistent state to work correctly.

How Claude uses it without being asked

When you describe an integration, Claude recognizes the patterns that need persistent state and sets up storage for them as it builds. You don't say "cache this", "remember that", or "store this between runs" — Claude reaches for storage on its own. Common patterns it handles automatically:

  • Identity resolution cache — when an automation syncs records between two systems, the first time it sees a given email, phone, or external ID, it searches the API and caches the mapping. Every subsequent run for the same record skips the API call entirely.
  • Hash-based change detection — when polling a system for changes, Claude stores a hash of each record's state. On the next poll, if the hash hasn't changed, the record is skipped. No redundant downstream work, no redundant API calls.
  • Per-tenant settings — when a workflow has customer-specific config, mapping tables, or feature flags, Claude loads them from stored settings at the start of every run. The customer changes a setting once; every subsequent run reads the new value.
  • Conditional content — when an email, SMS, or document has optional sections, Claude composes each section based on whether a corresponding storage value is present, instead of building branching logic into the content step.

You see the stored data in your APIANT dashboard once the automation is built.

When you might want to mention it

You don't have to. But if you have a specific preference ("keep this for a year, not 90 days", or "don't bother caching that, the lookup is cheap"), you say so and Claude adjusts.

Retention tiers

For when you do want to think about it, storage is grouped into four tiers based on how long values stick around:

  • temp_ — auto-deletes after 90 days. Default for short-lived state.
  • temp180_ — 180 days.
  • temp365_ — 365 days.
  • no prefix — never auto-deletes. Use sparingly; ungrouped storage grows forever.

Claude defaults to temp_ unless you ask for something longer.

What it isn't

This isn't a database for queryable data. There's no querying, no joins, no filtering — only key lookup. If your automation needs structured records you can search, integrate a real datastore (a database, a spreadsheet, a no-code data platform) as another action in the automation.

See also

Related docs

Last updated May 4, 2026