Storage by Zapier is a built-in action that saves a value under a key and reads it back on a later run, so a Zap can remember what it did last time without adding another app to the stack. It is available on every plan, including Free, and Storage steps do not count toward task usage. You connect it once with a Store Secret, then build with actions such as Set Value, Get Value, Increment Value and Push Value onto List. One store holds up to 500 keys, key names are capped at 32 characters, and a key that sees no activity for two months is deleted. What follows is the five minute setup, three builds worth copying (duplicate blocking, a daily counter, round robin lead assignment) and the limits that quietly break Storage workflows. Values written by one step and read by another cover most of what people actually need from it.

What does Storage by Zapier actually store?

A Storage step writes a key and a value into a store that is tied to one Store Secret. Zapier describes that secret as a username and password rolled into one: the same secret always points at the same store, and a new secret creates an empty one. Nothing is kept inside the Zap itself, so a value written on Monday is still there on Friday, in a different Zap, on a different schedule.

Values are plain text or numbers. Lists work through the push and pop actions, and child keys let you keep one counter per user or per month under a single parent key. What you cannot do is query it. There are no columns, no search, no history and no page where you look at the contents, so a store is a short memory rather than a database. Everything it offers is listed in the official walkthrough: Storage by Zapier in Zapier’s help center.

How do you set up your first Storage step?

The setup takes five steps and no code.

  1. Add an action step in the Zap editor and search for Storage by Zapier.
  2. Pick the action event. Set Value is the right first choice because it only writes.
  3. Create the connection. Zapier signs you in with your existing account, then asks for a Store Secret. It has to use UUID formatting and stay within 36 characters, and it should be treated like a password rather than a project name.
  4. Fill the Key and Value fields. The key is the name you read later, so keep it short and predictable, and map the value from a trigger field such as an email address or an order number.
  5. Test the step. The test writes the value and shows it in the data panel. Leaving the Value field empty removes that key instead of storing a blank one.

Storage is available on the Free, Professional, Team and Enterprise plans: Storage by Zapier integrations.

Which Storage action do you need?

Action What It Does Where It Fits
Set Value Writes a value, or deletes the key when blank Markers, flags, timestamps
Get Value Reads a key, and a missing key can count as failure Comparing runs
Get and Set a Child Value Reads and writes a key inside a parent key Numbers per user or month
Set Value If Writes only when the stored value still matches one you read Safe read and write pairs
Increment Value Adds or subtracts an amount Counters, round robin
Push Value onto List Appends an item to a stored list Queues and batches
Pop Value from List Removes the first or last item Working through a queue
Get List Values Returns a list as text in a chosen format Daily digests
Remove Value Deletes a key, with a related action for child values Cleanup
Get Secret Hands the secret to a code step Python steps

Which one you need depends on what has to survive the run. A single remembered fact takes Set Value and Get Value, counting takes Increment Value, queues take the list actions, and a Python step takes Get Secret: use Python code in Zap workflows.

How do you stop duplicate rows with a stored key?

Duplicate blocking is the classic build, and the order of the steps is what makes it work.

  1. A trigger fires with a record that carries a unique field, such as a message ID or an invoice number.
  2. Get Value reads a key built from that field. A Formatter step in front of it keeps the key short and stable, for example seen-inv-1042.
  3. A filter continues only when the value does not exist. A record that was already processed fails the filter and stops, which is exactly what you want.
  4. The action that creates the row or record runs.
  5. Set Value writes the marker as the last step of the Zap.

Writing the marker last matters. If the run fails halfway, nothing has recorded the ID yet, so your own dedupe never blocks the retry. The filter half of this build lives in a filter step, and its failure modes are covered in Zapier filter not working. When the destination is a Notion database, the same marker replaces the search step that keeps duplicates out there, which is described in Zapier and Notion workflows.

How do you count events per day without a spreadsheet?

Counters are the other classic build, and they do not need a sheet.

  1. Add an Increment Value step with a key made of the word counter plus today’s date. A Formatter date step supplies the date in YYYY-MM-DD, so each day gets its own key and the count restarts by itself at midnight.
  2. Increment by 1 on every run.
  3. Add a separate scheduled Zap that runs late in the day, reads today’s key with Get Value and sends the total by email or chat.
  4. Remove Value in that scheduled Zap, so old counters do not pile up against the 500 key limit.

When the daily numbers have to live somewhere people can read them, a spreadsheet is the better long term home for the totals, and the weekly pattern in how to automate an email report from Google Sheets shows how to build the sending half. The counting half stays in Storage because it needs no tab, no header row and no scheduled formula.

How do you round robin new leads across a team?

Round robin is the build where Storage earns its place, because the counter has to survive between runs.

  1. Increment Value with a single key called lead-counter, adding 1 for every new lead.
  2. A Formatter step takes the modulo of that number against the size of the team, so a team of four produces 0, 1, 2 or 3.
  3. A Pick from List step in the same Formatter maps each result to one name, where 0 selects the first person, and the owner field is set from it.
  4. Write the counter back when it has to stay small. Set Value with 0 once the number passes the team size, or let it grow, since one large number is still one key out of the 500.

Two cautions belong here. The counter is shared state, so the key name has to be one that no other Zap writes to. And when the rotation feeds a database, the person field usually has to exist as an option before the Zap can write it, which is one of the traps in Notion automations.

What breaks a Storage workflow?

  • Key names longer than 32 characters. A raw JSON body or a full URL fails as a key, so build it in a Formatter step and keep it short, like seen-inv-1042.
  • A store that fills up. One secret holds 500 keys. Date stamped keys add up, so remove them once the report is sent.
  • Values that are too large. The help center allows values up to 1 MB, the API page says under 2,500 bytes, and an older help article says 25,000. Store IDs, counts and short text, and leave the payload in the destination app.
  • Two runs that touch the same key. A stored value can change between your Get Value and your Set Value. Set Value If is built for that case, because it writes only when the current value still matches a previous value.
  • A secret shared too widely. The same secret means the same store, so two Zaps can overwrite each other’s keys.
  • The success toggle on Get Value. When a key is missing you choose whether the step counts as success or failure. Left on the default, the run continues with an empty value, and empty values slip past filters.

Current numbers live on the Storage API reference.

Storage, Tables or a spreadsheet: which one fits?

What You Need Storage Tables Spreadsheet
Remember one value between runs Best Fit Workable Extra Step
A queue of pending items Workable Good Awkward
Rows A Person Edits Or Shares No Yes Yes
Months Of History No, Keys Expire Yes Yes
Counting Against Task Usage No No No

The choice follows the shape of the data, not the price, because none of the three draws on task usage. Storage holds single values and short lists, which is what a Zap needs and nothing more. Zapier Tables holds rows with fields, which is what you want when a person has to open it, filter it or share it. A spreadsheet is the familiar middle ground and the slowest of the three to read from during a run. Zapier’s own comparison of the three tools is here: data storage solutions for your workflows.

FAQ

Does Storage by Zapier count toward my task usage?

No. Zapier states that Storage by Zapier does not count toward task usage, and the same goes for Digest and Tables.

Can two Zaps share one store?

Yes, when both connections use the same Store Secret. The key space is shared, so prefix keys with the job they belong to, for example leads-counter instead of counter.

Do keys expire on their own?

Yes. A key is deleted after two months without activity, and any read or write restarts that clock. A value that has to last for years belongs in a spreadsheet or in the destination app.

Is there a page that lists everything in a store?

Not in the editor. Read the key back with Get Value, or list a group of keys with the REST API at store.zapier.com.

Sources