Rebuild a Zapier Function After September 1

Your production Zap can stop the day a platform retires a feature. Zapier Functions is set to retire on September 1, 2026, so a stopped function needs a rebuild. Rebuild it as a Code by Zapier step. Code by Zapier cannot store API keys or tokens as secrets directly in code. Treat it as a solo incident: recover the code, rebuild the triggers, move secrets, and test before trusting it again.

Code by Zapier is the rebuild path

The old function is a specification: it already shows the inputs, outputs, and edge cases. Code by Zapier supports JavaScript and Python. Use the language you already know, so a JavaScript function stays JavaScript and a Python function stays Python.

It also makes npm and PyPI packages available, adds AI support for generating code, and includes a Zapier SDK that is JavaScript-only. Use the AI help to draft the first version, but keep the logic under your control. A function that once lived in one place may now need a code step, an API step, and a trigger for each entry point.

Run times go up to ten minutes. Note the runtime limit before pasting in a long-running script.

The gaps decide the rebuild

Some functions are a single file, the easiest case. Others are a folder of helpers or a shared library. Some secrets are visible; others are masked. Write down which case you have before you start. A multi-file function needs a clear owner for each helper. A masked secret needs a new home before the old one disappears. A masked secret is the quiet one: it may have worked for a long time, then become hard to copy. Plan to enter it again.

Do not rebuild everything at once. Restore the smallest production path first: a single trigger, a single code step, a single output. If that path works, add the next trigger. This keeps the incident small and gives you a working version you can compare against the old behavior.

Five steps restore the workflow

• Inventory the old function. Write down every trigger, input field, output field, app, endpoint, and secret the workflow used. Note which fields were required and which were optional. A one-page list is enough.
• Recover the code. Copy the original function into a file, note the language, and list any packages it imported. If the code called another service, write down the endpoint and the shape of the request. Finish with a clean file you can read, edit, and paste into a new code step.
• Rebuild the triggers. If the old function had multiple triggers, give each trigger its own Zap, or route shared logic through a sub-Zap. Finish when you can start from any entry point and reach the same shared logic without duplicating keys.
• Adapt inputs, outputs, and secrets. Move keys out of the code. For unsupported apps or nonstandard endpoints, use API by Zapier with the Zapier SDK as the authenticated path. Stop when no key appears in the code and every external call has a clear authentication path.
• Test and publish. Run a sample payload, check the output, and verify the edge cases that broke before. Note any remaining gaps, such as multi-file helpers or masked secrets. Enable it only after the workflow behaves as expected.

The next recovery should be boring

Leave the keys out of the code. Put a small document next to the workflow: the trigger, the code file, the secret location, the test payload, and any remaining gaps. Keep the document beside the code, whether the code lives in a file or a note.

When a platform changes a feature, that document turns a panic into a checklist. Count the hours you spend rebuilding, not just the dollars you save.