While building workflows in Make, I noticed something odd—Make refers to a webhook’s unique identifier as “Webhook UDID.”
From what I know, UDID (Unique Device Identifier) is normally used for physical devices, like in Apple’s ecosystem. But here, it’s being used for a webhook, which doesn’t really make sense. It doesn’t follow a standard UDID format, and it’s not related to devices at all.
I’m curious:
Is there a reason Make uses “UDID” instead of just “Webhook ID”?
Wouldn’t a more standard term help avoid confusion for developers?
Has anyone else found this a bit misleading?
As a developer, I love using Make to build and automate things, and I try to contribute where I can. I think small changes like this could make the platform even better for everyone.
Would love to hear thoughts from the community and the Make team!
Hey @TheMaker, welcome to the Make community! We’re really happy to have you here, and I appreciate you raising this—it’s a great observation.
I’m Daniel, a Product Manager at Make, and your post was shared with me because, well… you’ve got a point.
We are indeed misusing “UDID” in this context. My first guess was that it was just a mix-up with “UUID,” but that’s not the case—it’s really just an identifier. The reason for differentiating it likely comes from the fact that webhooks in Make have two different IDs:
• “Webhook UDID” (alphanumeric): This one appears in the webhook’s public URL (e.g., hook.eu1.make.com/{hooksSoCalledUDID}). A more intuitive name might be something like publicId instead.
That said, renaming it is not trivial. The term udid is already baked into numerous API responses (example, another example), so changing it would be a breaking change for users relying on this parameter.
A potential solution could be to introduce a new parameter like publicId in API responses, update our documentation and UI accordingly, and plan a deprecation of udid over time. But given that this is the first time I’ve heard someone call this out as an issue, I’m leaning towards keeping it as is and simply improving documentation to clarify its meaning.
Would love to hear thoughts from you and others in the community—how big of a pain point is this in practice? If there’s strong feedback, we can explore potential improvements!
Thanks for the explanation! It definitely helps clarify the reasoning behind using “Webhook UDID” and the complexity of changing it.
I agree that adding publicId as an alternative could be a good long-term solution, especially if it comes with clearer documentation. However, based on my experience, confusing terminology like this can lead to misuse, particularly for developers who are new to the platform.
Since renaming the field entirely might not be feasible right now, perhaps an interim solution could be adding a clarification directly in the UI next to this field, or even including a note in API responses (like a comment in the returned JSON payload)? This might reduce confusion without breaking existing integrations.
Either way, I really appreciate your openness to feedback – it shows that you genuinely listen to the community!
We’re really happy to have you here, and I appreciate you raising this—it’s a great observation. 
