Collection IDs can change?

I hesitate to even ask this, as I’m sure it is a problem on my end, and not with Webflow. That being said, is it possible for Collection (and Item) IDs to change over time?

My application is powered by the Webflow API and I’ve begun to notice more and more 404 responses from the API. After some investigation, I discovered that this was happening because the Collection IDs stored in my database no longer match the Collection IDs in Webflow. I know this because the slugs still match.

This was very surprising, as I would not expect the primary identifier to change. Is there a scenario where this could happen?

1 Like

Hi @cspags, thanks for your post. Collection IDs can change under the following circumstances:

  1. The site is restored from earlier version
  2. The site is duplicated

Let me know if any questions and thanks in advance.

2 Likes

@cyberdave thanks so much for your reply and the information. I was not aware of the first scenario, restoring from a backup. Is there any way to detect when a backup is restored? I checked to see if a webhook gets triggered or any data on the Site model changes (thought maybe the database field), but neither happened.

Ultimately though, knowing this now, it looks like the solution is to rely on the Collection slug. Even though users can modify this field, it’s a rather severe action, hence the redirect warning that the Webflow editor provides.

Thank you again, really grateful for the helpful reply.

I’m also having the same problem. My collection IDs keep changing and breaking my integrations.

I don’t recall having manually restored any backup or duplicated my website.

Is there any other reason why this might be happening?

Hi,
I also have this problem, in my case because of backups (which is not obvious at all ) Are you going to fix this problem? I would like to be able to restore the site from earlier version so that the ids remain unchanged.

1 Like

Hi @Elena_Laenko,

At this time, anytime you restore from a previous version the Collections and item IDs will change. I am not sure if this will be fixed in the near future. But this has to do with a reverting of the database.

You can add this to our wishlist if you wish: https://wishlist.webflow.com/

Best Regards,
~ Brandon

@cyberdave @QA_Brandon Please add a warning before a backup is restored, so people who rely on the IDs will think twice.

3 Likes

That has been added as it seems

It’s crazy how many things the backup can mess up, all the reference and multi-reference fields, not even talking about API and zappier. Need backup of the back up. Wait? If i back up to the version before backup will it be fixed or it will generate another random set of ID?

1 Like

Hi,

For every backup restore done, new CMS Item and Collection IDs will be created.

Have a Great Day and Happy Designing,
~ Brandon

Hey @QA_Brandon @cyberdave does this also apply to transferring site ownership?

I have recently set up a Team plan to allow for external partners to access and work on our Webflow Sites Ecosystem but I’m scared to transfer the sites across to the team because the Collection and Item IDs may change which will upset the Zapier, Parabola, Airtable, Memberstack, Outseta and Stripe integrations I have in place.

I have also sent an email to your support inbox.

Many thanks,
Frazer

I run into the same problem. I did not see any warning - or at least they were not visible enough.

This is a huge issue, since I had some serious automations running. It is possible to change this, so ID can stay forever even when use the backups.

Like now, the backup is totally useless, no?

Any best practice?

Thanks,

Patrick

The CMS Item ID does not persist after a restore; it’s mutable. Webflow should decouple the CMS from the restore function as an option, giving you a choice.

There is no workaround other then possibly creating your own GUID and using that programmatically. Of course this would be an issue with other integrations using the API since there is no search method. I think of WF’s newest commercial where “everything just works” except it doesn’t.

1 Like

I faced a similar issue. Restore was the problem.

It is a disaster here as well. Two and a half years at least and still nothing has been done. Backup is useless, when it needs to be a critical tool in a developers tool box. The sidebar here says the “Topic has been solved”. It clearly has not.

1 Like

If you’re using Collection IDs to update Webflow CMS data, consider using an automation platform that lets you configure the “name” field for updating the reference fields.

Byteline provides this functionality, so you don’t need to use Collection IDs for your logic.

The above screenshot shows a simplistic example, but you can use an expression to refer to the value of the “name” field. It finds the record from the referenced table with the “name” field as “Acme Inc.” and then uses its item ID to create the reference. Learn more.

I agree. This isssue has not been resolved. I am running into an issue on our company’s website as well. I wanted to restore from the backup which seems like the best solution, but as soon as I read that message, “Restoring will change some of your Collection IDs, which may break integrations that rely on the CMS API.” I knew I was in trouble.

One of my components which has 4 instances in our website has somehow been deleted. I have been trying to copy the component from a duplicate of our website, but so far it has not proved successful.

Can someone from Webflow Support provide more insight on this thread and possible solutions? We are now in 2023 and this still seems to be a pain point for some of us.

Thank you in advance.

I was facing a similar problem. Restore was the issue.

@cyberdave, can you clarify the rationale behind this change of Collection IDs so we can explain to our clients? Thank you in advance.

There really isn’t any good rationale you can give to clients here, it’s just a design decision that Webflow’s technical team made to support the backup and restore process efficiently.

From what I can tell, any time a backup is made ( which happens a lot ), the CMS data is cloned and those cloned items get new ID’s so that they can be stored in the database alongside your regular CMS content. When you restore, the version you’re retrieving now has those new IDs.

Yes, there are other design architectures that could have resolved this, using a persistent ID, and a “current live project” indicator but this actually creates a lot of complications under the hood with refs & multi-refs, and it’s not clear that added complexity/fragility would benefit everyone.

Consider, let’s suppose ID’s were persistent across backup & restore. You have an API integration which uses your DB of products. Then you restore a backup because the client needs to revert a major UI design piece. Now you still have your same products DB with the same ID’s, but the content is several versions older. ID’s match but content is no longer in sync with your integration. Some items are missing. Other items exist, which were later deleted.

Is that better? I’m not sure.

Personally I’d prefer that the CMS and the Site were decoupled so that you could share a CMS across multiple sites, or use multiple different CMS’s in a single site. Then features like country lists, zip code lists, etc. could become library CMS resources. But that’s a complex path as well because you then put the burden on the “schema contract” between the CMS and the site. If you change the CMS structure, the sites using it are broken until they adjust for that change.

For most people, that added complexity isn’t beneficial.

If you want to put a positive spin on it, you could say “this approach ensures that your CMS data is backed up with each version as well, so you know it’s safe.”