Authentication scheme for new Workflows API

I’m trying to update my command line tool,, with the new Workflows API, which makes POST requests to a new endpoint. I’ve figured out the transit encoding format, but I can’t figure out how to authenticate.

I’ve tried sending my token both as part of a Basic Authentication header, and using the old ?circle-token=token format, but no luck.

The frontend authenticates with a “ring-session-id” cookie. I would rather not authenticate by making requests to the website to get a session ID, CSRF token and then sending that back to the API, but I would if need be.

Is there any easier way to authenticate to the API?


Kevin – these APIs are in flux right now, so I’d recommend holding off a bit. We’re working on a GraphQL API, but it’s not yet stable, so any work you do against it is subject to breakage without warning. As you’ve seen, we also haven’t yet implemented our token system fully (many of the queries are only accepting our cookies today). We hope to get this stabilized later this year and will be making some announcements when that happens. In the mean time, you should consider anything other than our 1.1 API to be highly unstable.

Okay, in the meantime the old API jobs currently have pointers to the workflow they’re associated with (if any). Could you add a field that indicates whether this is the last job in the workflow, or the current workflow status?

I need one or the other to determine whether I can exit when a job completes, or whether I should keep waiting for other jobs to appear.

This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.