[yodon]

I'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]

1. 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.

[yodon]

This sounds great - very sensible answers for an early stage product.

Re: your mention elsewhere of adding language support beyond Python, I'll call out C# (first choice) and/or Typescript (2nd choice) as my personal favorite votes.