So the `bundle.meta.zapier` was “deprecated” (which wasn’t obvious if you haven’t look in the docs for some time) and was changed without notification, from what I can see there is no way to access “zap ID” anymore, and the support can’t help with that either.

If you needed that, then you are screwed (as i’m) and you have to change the integration to match yet another limitation..

If it was “deprecated” then Is there any other Unique Key that would use to manage zaps in my system?
How did you manage it?

Unfortunately there is no such value anymore. Right now I’m creating the “connection” on my side when `performSubscribe` is called, and the “connection” then is removed when  `performUsubscribe` is called. There is no other way anymore, as the zap action can be many-to-one (it was one-to-one).

bundle.targetUrl , the URL used to push messages to the Zap, is an alternative unique identifier for the Zap.

From what I’ve seen the `bundle.targetUrl` changes on every `performUsubscribe` action (when the zap is enabled). Unless there was some change and now the `bundle.targetUrl` is unique all the time?

Ah, yes, that is correct.  It’s going to give you a handle to that “runtime instance”, not the zap definition itself. Which is also what bundle.meta.zap.id does now. There were some internal changes that manifested in these IDs changing.

So that I can better have this conversation with the team here, could y’all share how you were using zap id, and what your use case is for a permanent identifier for the Zap definition, rather than the instance of the subscription itself? That’d be super helpful. 

Just wanted to make sure, for now...there is absolutely no permanent identifier for a particular zap.
we have to use runtime-instances instead. Right?

Zap ID has been provided in the bundle during hook subscription requests as a largely undocumented feature in the current Zapier platform. Full transparency, some changes are going on in Zapier’s internal architecture and as a result some (about 20%) of Zaps stopped getting passed the real ID of the Zap. This wasn’t an intentional change and the team is looking at restoring the handling of ID for those requests. I don’t have an ETA yet. If this affected any of your integrations, sorry about that.

That said, we’re reviewing usage of Zap ID and may conclude that it might need to deprecated in the future. If your use case requires references to a user’s Zaps, I’d encourage you to look at the Partner API instead https://platform.zapier.com/partner_api/introduction.

I wanted to follow up on my last post here, as this topic developed a bit at Zapier after I posted and I wanted to clarify for future readers. bundle.meta.zap.id will no longer provide a reference to the Zap ID itself during subscription, for any Zap. It’ll be a string with ‘subscription:’ followed by a unique identifier for the subscription, not the Zap itself. 

We reviewed how folks are still using this value today, and for most this will still serve their purposes. Note that it’s now a string, not an integer value. Some have needed to adjust their data validation or storage types.

For those who want to provide their users with a link from their product to the Zap associated with the resthook on Zapier.com, have a look at Zapier’s Partner API and embed tools where you can accomplish that and lots more. More on the embed tool here.

Please let us know if you have any questions about the change or how to adjust to it, either here or at partners@zapier.com