Forced migration to FrameIO v4 will break my entire company's pipeline!

[jnorthest]

Yesterday we were extremely concerned to see a banner appear stating that our company’s Frameio account will be forcibly migrated to the V4 platform on March 24.

We rely heavily on the Frameio API and webhooks to automate our entire video production pipeline. Our ingest, review, version management, notifications, and downstream processing are all built around the current API structure. This is not a light integration for us. It is mission critical infrastructure.

We have intentionally held off upgrading to V4 because of widespread negative public sentiment surrounding the new platform, particularly regarding:

• Lack of API feature parity with Legacy

• Incomplete or missing endpoints

• Limitations around version stacking

• Changes to webhook behaviour

• Instability and inconsistencies reported by developers

• Missing workflow-critical functionality

This research document compiles public discussions from forums, developer channels, and user communities. The dominant pattern is consistent concern from power users and developers that the V4 API is not yet complete enough to replace Legacy in production environments.

For us, the limited version stacking capabilities alone are a deal breaker. Our workflow depends on predictable, controllable version management. Without this, our automation breaks.

A forced migration under these conditions effectively bricks our production pipeline. It is not a minor adjustment. It requires a full architectural rewrite of our automation stack, while core features are still reportedly missing.

This creates significant operational risk for teams that have built serious infrastructure on top of the Legacy API.

We are asking:

1. Is full API parity with Legacy guaranteed before migration?

2. Will version stacking functionality be restored to a level comparable to Legacy?

3. Is there an option to delay migration for API-heavy enterprise workflows?

4. Can Adobe provide a clear feature parity roadmap with timelines?

We understand platforms evolve. But forcing migration before parity is reached puts developer-driven workflows in a precarious position.

We are attaching the research summary for transparency and would appreciate direct clarification from the product and API teams

If other developers are in the same position, we would welcome hearing how you are handling this transition.

[CharlieAnderson]

Hi @jnorthest a lot of what you’re asking about can be found on our developer docs:

Frame.io Platform | Frame.io API Documentation

We have a migration guide there, SDKs for both Python and Typescript, and various other additional endpoints available.

If you could take a look over the endpoints that we have available on our developer docs and let us know if there are any missing methods that you need, that would be most helpful so I can prioritize getting those in queue.

[jnorthest]

Hi @CharlieAnderson,

Thanks for the helpful documentation. It’s aided me a lot in migrating over to the new API this week. I’m nearing the end of my migration to the V4 API and platform as a whole, so I wanted to share my initial thoughts and feedback while everything is still fresh. Hopefully you can pass this along to the relevant teams for consideration. I’ve verified that I’m not the only person running into most of these, so I imagine this feedback will resonate with other developers in the community too.

---

API Issues

Guest Commenter Names Not Available via API

There’s currently no way to retrieve guest reviewer/commenter names through the API. If a guest leaves a comment on a review link, their name simply isn’t included in the response. For anyone building notification or reporting workflows around comments, this is a significant gap - we need to know who said what. I’ve already responsed to this in another thread and shared my hacky work around for now. This was in the previous API.

No Way to List Assets Within a Share

There doesn’t appear to be an endpoint to list the assets contained within a share/review link. Being able to programmatically query what’s been shared (and with whom) would be really useful for automation and audit purposes. This was in the previous API.

Start Time Field Doesn’t Reflect Actual File Timecode

The start time field defaults to 00:00:00:00 regardless of the source file’s actual starting timecode. This means if a video’s timecode doesn’t begin at 00:00:00:00, there’s no way to derive the real timecode of a comment through the API. This is a blocker for anyone working in post-production where source timecode matters (which is most of us).

Comment Timestamps Occasionally Off by One Frame

I’ve noticed that comment timestamps are sometimes one frame off from where the comment was actually placed. I can’t identify a consistent pattern — it seems like a rounding error somewhere in the pipeline. It’s a small thing, but accuracy matters when you’re referencing specific frames.

---

Frontend Issues

Statuses Need to Be Back in the Top Bar

Statuses have been moved out of the top bar and buried within the fields/metadata panel. This is a big step backwards for usability. Clients won’t dig into a menu to set a status, they just won’t use it. And internally, we need to be able to glance at statuses quickly without clicking into anything. The old UI had this exactly right; there was no need to change it.

Version Stacks Don’t Update Dynamically When Created via API

When you create a version stack through the API, the UI doesn’t reflect the change until you manually refresh the page. In V3, the UI would update dynamically. This makes API-driven version management feel broken from the user’s perspective, even though it’s working correctly on the backend.

DELETE Keyboard Shortcut Removed

In the old FrameIO, you could select items and hit Delete to remove them. Now you have to right-click and open a context menu to delete anything. It’s an unnecessary extra step that slows down everyday file management. Please bring the keyboard shortcut back.

---

Happy to provide more detail on any of these, or help reproduce issues if that’s useful. Overall the V4 platform is shaping up well - these are just the rough edges I’ve hit along the way.

Cheers, Josh

[CharlieAnderson]

Hi @jnorthest thanks so much for the rundown and the feedback! Happy to answer some of your questions here, as some of them are available today. Please keep the feedback coming!

Guest Commenter Names Not Available via API

We are aware of this one, and after lots of talk internally we are investigating how to route these to the proper data base so that the API can show them. More to come.

No Way to List Assets Within a Share

This is known and on the roadmap to complete by end of Q2

Start Time Field Doesn’t Reflect Actual File Timecode

You can configure what’s returned in the API. The default way is based on frame count (start tc of zero) so when timestamp returns a number, it is the frame count of that file.

Using the timestamp_as_timecode param will return the timestamp of the comment based on the file’s inherent TC:

Comment Timestamps Occasionally Off by One Frame

This is known and due to the way the backend and front end communicate. I go into more detail here.

Statuses Need to Be Back in the Top Bar

This is customizable inside of Frame. You can show what is shown on an asset via Fields dropdown:

and it will show up on the asset like this:

Also if the side panel is open, it is still at the top:

Version Stacks Don’t Update Dynamically When Created via API

Thank you for this, have reported it to the subscription team.

DELETE Keyboard Shortcut Removed

This is available today, you may need to configure your keyboard shortcuts inside of frame (click your account icon in the bottom left and it is just below Settings

[jnorthest]

Thanks @CharlieAnderson!

I’ll take a look at these.

The first thing I wanted to ask is how can I make this the default share link option to have the status as the featured field?

I have to set it each time I make a share link, and there doesn’t seem to be a way to save this for all share links. The featured field solves the issue of putting the status in a visable place for the client on the player page.

[jnorthest]

Another issue I’ve found is the parent_id for a versioned asset is the id of the of the version stack, not the id of the parent folder which is what I’d expected. It would be good to either add a parent_folder_id to all assets or versions should have an additional versions_stack_id and keep parent_id for only folder ids.

Currently, trying to find the parent folder of an asset requires alot more code since it has to navigate the parent_id difference between versioned and non-versionsed assets.

Is there a better way to easily get the parent folder id of any type of asset (versioned and non-versioned)?

[CharlieAnderson]

there doesn’t seem to be a way to save this for all share links.

Share links always default to Status as the main field, but if you wanted to default to something else this is nor possible today. I have created a ticket with the Share team and will follow up!

Is there a better way to easily get the parent folder id of any type of asset (versioned and non-versioned)?

Version stacks are a different asset type than files or folders. If you get a 422 “Unprocessable Content” with the Show File, then you would need to run either Show Folder or Show Version stack in order to get the Parent ID of that asset

Hope this helps! LMK if there’s anything else I can help with