Happy new year everyone!
The title says it all: I can definitely access it using an outside server, such as the following image:
However, I need a way to access it from the designer in order to use it in the front-end. Example:
Anyone from the Webflow team knows if there’s any API that allows me to access the auto-generated ID for a given collection item?
Thanks!
Ps: @cyberdave @webdev … I’m @ing you guys in case you know of something! Thanks
@Jeandcc - You could copy the value shown in the designer when editing a cms item (BOTTOM) and place it into a new field in that collection, then it would be accessible. Happy New Year.
Hey Jeff! Thanks for that! I actually considered doing that and I might do it as my last option. I just felt that it was a bit too “manual”. I didn’t really want the client doing that kind of manual work.
Nevertheless, thank you so much!
Hey all whats the progress in this!? I cant actually understand how this is not naturally included. I need item Id’s in literally every external call.
So are we saying the only way to do this atm is to duplicate the webflow CMS Id for each item in a collection? Or am i missing something?
Thanks
I also need the ability to access item ID and have it auto add to the CMS item. Otherwise zapier will never auto update.
Hello Everyone.
I don’t recall what I did for that specific project, but one way I would take care of that need nowadays would be adding a webhook listener to the “collection_item_created” event, and update a custom field of that item with its id for every new item that would trigger that webhook call.
I would do it through cloud functions, but zapier and parabola seem like a good fit for something like this in case you are not comfortable with code.
This article was super helpful! I had the exact same issue and managed to implement the solution that @Jeandcc recommended.
I recorded the setup process and put it up on youtube so you don’t have to do as much trouble shooting as me 
I hope it saves you lots of time!
Hi @DuncanHamra . Great vid!!!
Couple of tips:
Your workflow filter will stop working after someone restores a backup, given that the collection id would change. I would change your filter to be based on the collection slug.
I would also recommend using the patch API operation instead of the update item. That way I believe you only need to map the newly created collection id field, instead of having to map mall the other fields.
Also talking about backups: collection IDs change after a backup restore. You could create a flow that goes through all collections and collection items after a backup is restored and updates their IDs accordingly, and have that workflow available to be manually triggered every time a backup is restored.
All those issues with collection IDs are the reason why I’m currently preferring to do things based on slugs rather than on collection IDs
Great tips!! I didn’t realize that would happen if you backed up the site 
Strange that it works that way 
Good approach @Jeandcc
The one thing that’s bitten me about that is the desire to change slug’s at times without realizing the adverse effects of that.
One field serves two, totally unrelated purposes.
I’ve now moved over to creating a custom field that is wholly dedicated to just this purpose and also named that field as such.
It also greatly helps with Lookup Tables.