5 ms·
Show HN: Strada – Cloud IDE for Connecting SaaS APIs
Hi HN! I’m Arash, one of the founders of Strada (https://www.getstrada.com https://www.getstrada.com), a cloud IDE for building automation workflows across your company’s SaaS apps. Strada handles integrations, triggers, infrastructure and observability while letting you write core workflow logic in Python (more languages soon). It's for teams that hit limitations with low-code tools while building with internal apps — eg. Zendesk, Jira, Salesforce, Slack. You can access our docs at (https://docs.getstrada.com https://docs.getstrada.com).
While working on our first product (a unified accounting API), we learned that as companies grow, their integration teams become more technical but typically still use low-code tools. We also observed that as LLMs are becoming popular, these teams (usually outside of engineering) are adopting more code. For example, we spoke with multiple companies that generate integration code with an LLM and use it in their low-code platform.
Unfortunately, most integration tools are not designed with code as a first-class citizen. They often have limited support for external libraries, restrict how variables are used, and limit how code blocks interact with other workflow steps. But integration developers put up with them because stitching together authentication, scripts, APIs, infrastructure, and observability is time consuming and not a core focus for their teams.
Instead of drag-and-drop blocks, we chose code as the main interface. Tasks that are frustrating in low-code tools become simple with code: conditional logic with layers of branching, complex transformations, or problems that an external library already solves (for example, redacting personally identifiable information with the scrubadub library [1]). Each Strada workflow is a contiguous Python script, and every action configured in the UI can be invoked like a function. We started with Python since it’s popular with teams outside of engineering, like IT, Data, and Ops.
Our goal is to help integration builders focus on logic unique to their business by simplifying everything outside of that: - Integrations: we handle authentication and provide abstractions for common app actions; - Triggers: workflows can be triggered by a webhook or run on a schedule; - Infrastructure: one-click deployment with automatic scaling; - Observability: detailed logging of workflow actions, payloads, and errors.
Today, customers use Strada for workflows like Customer Support (receive Zendesk ticket webhook, remove sensitive information, perform sentiment analysis using OpenAI, and escalate problematic tickets) and Customer Onboarding (receive webhook with new customer data & files, transform to expected format, send request to third-party API, send request to internal endpoint).
What we're currently working on: - More enterprise app integrations; - A self-hosting option; - More runtimes in addition to Python; - AI for code generation.
We’re excited for you to try it and share your feedback!
[1] https://github.com/LeapBeyond/scrubadub https://github.com/LeapBeyond/scrubadub
- QuinnyPig 3y agoI really like where you split the difference between “no code” and “you’d best be a decent developer to use this.”
- arash-khazaei 3y agoI appreciate it - it is an important distinction!
- yodon 3y agoI've been waiting for someone to build this (or build what I think this is). A couple questions: Do you handle retry on failure and exponential backoff on rate limiting? (I'm hoping the answer to both of these is yes.) Do I have to worry about rate limiting my calls to your platform, and if so do I have to rate limit them at your rate limit or the 3rd party's rate limit or ? (I'm hoping the answer to this is within reason I don't have to worry about rate limits, you just queue up my calls and forward them at the right rate.) Is there a way inside the custom Python code to make an arbitrary 3rd party endpoint look idempotent to outside callers? (Hoping for this to be yes.)
- arash-khazaei 3y ago1. Currently, we expose the status of actions (success/failure boolean), plus any additional metadata (status code, any http response header) so that you can retry (that's the nice thing about it being fully in Python - an `if` or `for` loop is easy to write). We are working on allowing you to configure the retry mechanism within the action, so we handle it on your behalf. However, for now we didn't want to be too prescriptive on what should happen on failure. 2. You do not have to worry about rate limiting calls to our service. We enqueue each request and respond with a HTTP status `201`, and our worker cluster will start processing the job. Within the workflow, 3rd party API calls can be rate limited, but for now we leave that to the discretion of the workflow author (see 1.) 3. I may need a bit of clarification on this one. Is the question whether you can provide idempotency key when making a request to a 3rd party endpoint? If so, yes you can. We have simple abstractions of common actions (for example sending a message in slack, or creating contact). However, you can always build your own custom action that sits on top of the underlying HTTP request, and therefore you can pass any additional parameter (idempotency key) in this case.