Show HN: We built a developer-first open-source Zapier alternative

That was the final straw what led a friend and me to try to do what you’ve done.

We had started off using Zapier, and it’s horrendous objects & arrays handling, then moved on to Step Functions, then gave up on what we were initially doing to try and build a workable alternative.

With a cumulated grand total of 6 months of experience, we had no idea what we were getting into.

Anyway, the point is: thanks for making this.

They have a full in-browser editor that handles many-to-many API integrations with autocomplete and helpers. They also have a CLI that lets you work with your favorite editors.

I think what often gets missed and what gives zapier great power is the developer platform that can let devs build anything! I have a lot of custom integrations with apps that support use cases that afaik only I have. It is incredible effective.

1. Your API key with us can either be passed into the Trigger constructor or you can use our TRIGGER_API_KEY environment variable. For the API integrations we provide, we handle API keys for you and they're added inside the dashboard UI. For everything else: as the workflows and files are just code on your server you can use environment variables (or your preferred alternative) to inject secure values.

2. When a workflow step that requires OAuth is hit, the workflow pauses and prompts you to sign in. After you've signed in the workflow continues where it left off. You only need to connect each service once per organization. You can sign optionally in multiple times to the same service and switch connections where needed, e.g. multiple separate Slack workspaces.

GitHub star to Twitter follow is a great idea. You could achieve that right now by using our GitHub integration and our fetch call (which auto-retries with exponential back off and logging in the dashboard). We'll add a Twitter integration soon so this is really easy and publish it as an example :)

3. We have detailed error messages attached to the step that failed but don't currently have a way to hook into this like you describe. This is a great idea, I've added it to our task list.

4. Exactly right, each "step" is a block in the UI with clear inputs and outputs. We would really like to have a graph view. That'll be especially useful when you put loops in the code, and of course branching.

5. 100%, making this work well with AI code generation would be great.

6. This is a great idea, we'll investigate. Rather than just mapping 1:1 with an SDK we're trying to make the experience better. For example, with the normal Slack API you can't post to a channel name, you have to use an id. We make it so you can use the name and we deal with the hassle for you.

7. We'll look into this too. Integrations for interoperability could make this easier.

8. We're going to follow the GitLab/PostHog model. Like GitLab, the repository as a whole is MIT licensed but we can add some /ee folders in the future with enterprise features. We feel it gives us the right balance of being open source and gives us some protection from a competitor hijacking the project.

9. We will separate out the dashboard from the runners – this was a compromise so we could ship the first version faster.

10. We can relatively easily ship other languages SDKs and Python is probably where we'd start. Our core backend code will most likely remain in TypeScript.

Thanks again for so much feedback!