Transferring ownership of zap to another user results in catch webhook url being updated - why?

Hi @nakita 

When you copy a zap - the trigger webhook always changed, so I expect the ownership change triggered the same behaviour.

I agree a warning would be nice. I’ve flagged this to Zapier staff so they can clarify.

Thanks for the response @AndrewJDavison_Luhhu and for logging the bug @steph.n :) Please do keep me updated on any progress/resolution. Thanks

I suspect the same. Problem is, conceptually transferring and copying are two different ideas. Expected behavior of a “transfer” should be that the resource remains intact and is just moved. Its “identity” is the same. Copying is a duplicated resource with a separate identity and there for conceptually different as it’s not the original resource.

A warning would be very nice as it’s not intuitive this would change.

Ran into this issue today. Glad I found this discussion!

I support will’s suggestion of some kind of “hey here is a list of things that WILL CHANGE in your zap if you transfer ownership!” dialog or alert div when trying to transfer ownership. 

This *bug* just bit me very badly. Had a former employee leave. He had created about 30 zaps, many of them using a webhook. Before changing ownership of the zaps, I did run a test on a couple of randomly selected ones, and they all seem to work fine after making the change, so I went ahead and changed the ownership of all the rest.

Unfortunately, by chance, the zaps I tested did not have any webhooks defined in them, but about 20 of the others did. This broke several processes.

I am still trying to sort it all out, which will probably take me several days as many of the webhooks are called by external processes, which I don’t have a complete list for.

Zapier; PLEASE, PLEASE add a clear warning message about this when you click on the Transfer ownership option!

@nakita @willhoag @JesseLawson @RonW - I have updated our bug report to include everyone to be notified if/when this is resolved. Thank you for letting us know and we’ll be in touch.

@steph.n can you add me to this list as well? I just wrote into support as I just massively destroyed countless workflows because of this.

Also confused by anyone who is saying that this isn’t a bug. Transferring ownership is an account/security/permissions change. It makes no sense that a zap would have a variable catch-hook value that an account-ownership change would affect.

A catch-hook is defined as a unique URL to trigger that automation and unique zap to trigger. This can be a totally random number string, excellent! It should not be using the user-account owner ID as part of the catch hook URL.

@nakita and for anyone wondering what is actually going on, here’s an example of a Catch Hook within Zapier:

https://hooks.zapier.com/hooks/catch/3159322/obsg8s/

The 3159322 is the Zap owner’s ID (why would this be a good idea…?)

The obsg8s is a unique ID given to the zap itself (totally cool!)

Account-related variable fields should never be used in what is supposed to be a consistent and unique URL. Duplicating a zap is totally different. Yes, duplicating a zap should create a new catch-hook URL because it’s a totally separate zap. Changing ownership is not modifying the zap in any way, it’s still the same zap, thus, the unique URL should stay the same as it was.

This is definitely an oversight and bug and I’m reaching out now as I too just got bit massively by this.

Edit: Just got bit a second time, woohoo! Yeah so this doesn't only affect catch hooks created via the webhook connector, but also any connector that uses their trigger step as a simplified catch hook (which is actually a couple connectors that we are regularly using). While it's probably not many connectors, there are a bunch that do.

Just wasted easily 4-5 hours updating and cross-checking all our zaps and I'm still quite sure I missed some (not to mention the external systems that we push into Zapier catch hooks).

@alex oof, that sounds really frustrating, Im sorry.

I’ve added you to that bug so you’ll get an email when we have an update. 

We just got hit with this too and the attorney’s office this was set up for is very upset with us. We got no warning when the URL changed, the calls to the old URL never FAILED, but it also never showed anything in the task history. This went on for two weeks before it was caught. 

I agree with @alex in that the example:

https://hooks.zapier.com/hooks/catch/3159322/obsg8s/

The 3159322 is the Zap owner’s ID (why would this be a good idea…?)

The obsg8s is a unique ID given to the zap itself (totally cool!)

The webhook URL should not change based on a user changing. That is what teams are for, allowing multiple people to work on multiple zaps. The first variable should always be fixed as an ID for the parent account set when the account is opened OR by the account in the profile variable. The latter would be preferred as it would make more sense when looking for some code across apps. It would not be hard to check to make sure that variant was not already used too and let the developer know to make it unique. 

Second, when an OLD or invalid URL is used (or anything else that makes the URL invalid), the webhook SHOULD throw an error back to the client calling it. I know from other posts that Zapier is working to enhance the webhook so that it can be called on and return data, but THIS (in my opinion) is more pressing. 

Can you add me to this list too? This hit us hard and our client is not happy. We are mending fences, but the silent failure is something that is hard to overcome. 

Jim

Any update on this?  If this is not fixed how do I go about degrading my subscriptions?  Paying the additional to have Teams is useless with this bug.  This also caused us a lot of problems.

Another company here that got badly bitten by this issue. Can anyone at Zapier give us an update on the status of this one please?

Hi folks!

I don’t have an update on the bug, but I can see that the lack of warning is causing this issue to have a serious impact on your Zaps. I’ve escalated this to the team that handles the webhook app to ask if we’re able to add a warning so that people aren’t caught off guard by this. I’ll update this thread again when I have some news to share. 

Thanks for sharing your experiences with us. 

Hi everyone!

I’ve spoken to the team that handles the Webhooks by Zapier app and few other teams at Zapier. 

We may not be able to make a change to the behaviour here (ie the address of the hook changing) but we know that we need to add a warning message when you transfer or share a Zap to highlight the change. 

I don’t have an ETA on when you can expect to see that, but we’ve started the ball rolling. Thank you to everyone on this thread for letting us know how this has impacted y’all so that we can take action.

Hi, is there error fixed? how do we retrieve data from the old webhook after the ownership has changed?

Hi, is this now fixed? I may need to transfer ownership soon of an account with multiple catch hooks - I can’t afford for this not to work! Cheers

Hi there, @Bernard and @PeterCera. Thanks so much for reaching out. At the moment, this is still an active bug. I truly wish I had more of an update to provide however I can assure you this is on the teams radar. In the meantime, I’ve added you both to the list of impacted users and we’ll be sure to update the thread once a fix is in place.

So does anyone know _when_ this behavior actually shows up? I’m currently transferring ownership of a bunch of Zaps and did not bump into the problem (e.g. the catch hook endpoint did not change).   Does this have anything to do with ‘old’ zaps being made outside of a ‘teams environment’ or something?

However, I do remember this issue popping up for us last year. 

 Scrap that,  it is still occurring.  ;-)

Noo, I’m sorry to hear that @Lars P.! You had me super jazzed for you for a minute. 😔

I did go ahead and add you to the list of impacted users. We’ll definitely keep you and this thread updated once our team has a fix in place. 

The bug where the Custom Webhook URL changes upon ownership transfer has been fixed. However, now the catch webhook step simply shows the same URL as before but it doesn't work anymore. Seems like the bug fixing team didn't do proper testing.