Zapier had a command-line tool. That got my attention.
Goodword was using a small set of automations around beta access. One path handled a person redeeming an invitation. Another handled somebody joining the waitlist without a code.
The application sent a structured event to the automation layer. From there, the record could move into the tools used by the team for communication and follow-up.
We wrote down the expected fields and kept the two event types separate. A redemption and a waitlist request looked similar because both began with a person entering information. They represented different states and required different next actions.
The command-line option was interesting because it offered another way to inspect and manage those workflows. A browser editor is convenient, but it can be hard to review exactly what changed. A code-based definition can live beside other technical documentation and be tested in a more repeatable way.
This was an experiment, not a completed migration. What mattered was the structure: two signup events, documented inputs, and an attempt to make the automation easier to understand outside a visual editor.
We also needed a way to test without creating a real signup or sending an unintended message. A sample event could confirm that the required fields arrived and that an invalid request stopped safely. That check belonged in the documentation beside the normal path.
I shared the documentation with the engineering team and pointed out the command-line option. The current workflows still operated through Zapier. The next question was whether managing them as code would make later changes safer and easier to review.