The field name of the JSON response was automatically added a number at the end


In my collection setting, I have a field called sticky-title-1.

However, the field name of the response I get from the List Collection Items API has an extra number at the end like a postfix.


Somehow Webflow thinks I have duplicated field names and does this automatically for me although I don’t have any duplicates in my collection setting (it is not even allowed to).

How do I make this right? Is there any way to fix this and make the names match?


Unfortunately this problem has been around for awhile.

Webflow retains the very first slug it created for that field, even if you change it later. That first version is what appears in the API. Apparently the only way around this is to create a new field, with the correct slug, and migrate your data over.

Thank you, Michael @memetican

However, we don’t get to specify the slug we want when we create a new field, right? If I type the expected name again, then the auto “index” just increases by itself.
I don’t see any place to input a slug while creating a field, I see there is a placeholder for the slug while creating a new collection though.

Could you give me more details about the migration steps you mentioned?


Ah that’s right, I was thinking of item-level slugs, not field-level-slugs.

If you read the thread here, @bart laid out a general approach, however I think that it
will not work if you have already used the field name you want in the past. You’d have to create something new, e.g. name it Sticky Heading 1 and get sticky-heading-1 as a slug.

The reason for this is two specific behaviors in how field keys are generated;

  1. Every new field you create gets a unique field key generated, e.g. Field 1 becomes field-1. That key is permanent internally, and appears in the API, even if you rename that field later.
  2. Even if you delete a field, Webflow remembers the key you used, and prevents you from using it again. Instead, it appends a suffix like -1 to make it unique.

Here’s a simplified view of how field-key generation appears to work in Webflow.

In my case, I “fixed” it by completely exporting the collection as CSV, deleted the collection, recreated it carefully, and then reloaded the CSV. If you really need that field name in your JSON, I think that’s the only way to go, and I’ll explain why that is, later.

However that Collection rebuild can be painful. If this is a live site, with a big collection, and lots of refs into it, and is bound to a lot of collection lists… then this is going to be a bit like 3am open-heart surgery.

If the site draws visitors globally 24/7, you’ll be doing that surgery on a moving train.

I happen to do that kind of thing much too often, so if you need to, here’s how I’d approach this;

[ OC = old collection, and NC = new collection ]


  • Back up your site, in case of emergency.
  • Pause any external systems or automations that are reading/writing data from OC.
  • Block any FORMs or user actions that trigger those external automations.
    • If this is a busy site at 3am, consider taking it “offline for maintenance.”
  • Export your CMS Collection content as CSV

Phase 1- Move the old Collection

  • Rename your OC’s Collection slug. I’d append an -x, to differentiate. There’s a chance users could see this, so you don’t want e.g. -old.
  • To your OC’s Collection Page, add a <meta name="robots" content="noindex"> to the </head> custom code. We don’t want Google indexing this page at the temporary path.
  • Publish live, to make sure everything is sync’d at Webflow’s back end.
    • The site will still be 100% functional, just with that -x in Collection Page URLs.

Phase 2- Create the new Collection

  • Create NC, your new CMS collection at the same slug OC was originally at.
    • Be very careful to name the fields correctly, once, and to never rename them ever.
  • Create one record in your CMS
  • Verify the JSON through the API, to make sure you have exactly what you want
  • Load the CSV into the new Collection

Phase 3- Switchover

  • Fix any Ref fields in other collections that are referring to OC, they now need to refer to NC, and you’ll have to update that data.
    • You can find these in part by deleting all of the items in OC. Any that are linked to from other Collections will throw errors, and help you find that linked item.
  • Build out your NC Collection Page. On your OC Collection Page, you can unlink OC-bound items, and then copy those elements over to NC, and re-bind them. Yeah, I know. Agonizing.
    • Finding these OC connections is made much easier by Webflow’s “View Connections” tool, which you can find at the bottom of OC’s Collection Settings page in the CMS.
  • Copy over your custom HTML Head and Body code, but obviously not the noindex meta we created above.
  • Publish to Staging ( ) only. Verify that the new Collection Page is functioning properly, and the data looks good.

Phase 4- Switchover Cleanup & Validation

  • Delete OC
    • If anything is still bound, you’ll get errors… fix those bindings
    • If any other collections reference OC, change those to reference NC.
  • Publish to Staging, retest your changes
  • Publish to Prod

It’s 6am now, go celebrate with a beer.

Note that Webflow’s rich text fields have a link-builder with the ability to link to a specific CMS item- however that link is not tracked. If you rename that collection, or change the item slug, that link will not be updated and users clicking that link in your blog / press release / uni course will get a 404. However, in this particular workflow, your NC will end up at the same slug, and with the same item paths that OC had - so at the end of the operation, all of those links will work fine again.

So why is this insanity needed?

Interesting stuff, but that part got too long, so I’ve done a blog post here.

1 Like

Hi Michael @memetican ,

My god, this is so helpful! Really appreciate your detailed explanation.
I will try to run these steps. Wish me luck :slight_smile:


Nice, I hope to see a photo of you with that beer, smiling.