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. The archive records my discovery of the tool and the documentation we created for the existing automations.
The private messages include live endpoints, credentials, example addresses, and internal field names. They do not belong in a public article. None of those values are needed to describe the work.
The public-safe record is 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.