I’m the developer of the Frame.io integration for Coda.io. I also run a small production company, where we use lots of Zapier and API-based automation in our daily workflows.
I’m excited about some of the new v4 API features, but one roadblock I’m hitting is that developer tokens are being replaced by Server to Server (S2S), and S2S is only supported for Enterprise accounts.
While I understand that this kind of tier-gating makes sense in certain situation, here’s my plea for S2S for the people:
It’s not just large enterprise that wants to integrate Frame with other tools. If a small company like mine has been doing API stuff with Frame for years, I can only imagine that the use cases will explode in the vibe coding era.
Oauth 2 is not an appropriate substitute in many situations because of the 30-day timeout (I’ve run into problems where automated systems are failing because they need to be reauthorized periodically)
Oauth 2 is cumbersome to set up for quick prototypes
Public tools that help enhance the usefulness (and grow the customer base!) of Frame are often coming from outside of large enterprises (I’m currently building an AI version stack comparison engine, for example). I believe Adobe can expect to see ROI by providing an easy, democratized developer experience.
100% Agree. I’m currently exploring switching our company over to frame.io and this is a roadblock i’m hitting to meet feature parity with our automations set up with our current tool.
Thank you for raising this. We hear you, and appreciate you taking the time to share this feedback here.
We’ve been discussing internally and are currently looking at options for server-based API authentication as a solution. There isn’t a timeline we can share just yet, but it’s definitely on our radar.
We’ll be sure to provide any updates as things move forward. In the meantime, please feel free to share additional feedback on this as it comes up. Having in-depth context is very helpful as we continue to work on this.
I think my 30-day timeout problem might be moot, I think the platform I was developing on wasn’t handling the refresh tokens properly, which resulted in requiring user sign-ins every 30 days. Do you do anything idiosyncratic there or is it all fairly popular OAuth config on your end for that? The integration in question was a Coda Pack (like a plugin), and Coda’s SDK handles a lot of the OAuth business without the opportunity for developer intervention.
So at this point my biggest server-to-server request is for quick prototyping.
hi @nhe our TTL for access tokens is 14 days, and the refresh token changes after 7 days so as long as you have logic to capture whatever refresh token is returned when initially authenticating or when calling the refresh endpoint, and then using that when needing to refresh, you should be good to be authenticated for extended periods of time.
Thanks, yeah it’s just that I’m not in control of that logic. But if that’s a common OAuth pattern, I think Coda should support it (or should be able to). I’ll take it up with them.
Ys it is a common OAuth2.0 pattern, the only difference is the refresh token does not change when you use it UNTIL day 8. Changing the refresh token on every request is a OAuth2.1 feature.