 Hello, I want to go over an important subject about webhooks and it is how to test webhooks. So one way to test webhooks is to kind of like trigger webhooks by adding aliases or whatever, but that's kind of cumbersome to just like add an alias just so you can trigger a webhook. And actually, weights and biases offers a way to test webhooks, like a specific testing functionality. So let me show you that right now. So if you recall, the webhook code looks something like this. It's a web server, and it's using FastAPI. And if you're familiar with FastAPI, we're defining a data model that expects the payload to be a certain schema. So you're expecting a payload to have all of these fields, event type, event author, alias, artifact version, so on and so forth. And if you send a payload that doesn't conform to the schema, then FastAPI is going to throw you an error. Specifically, PydI was going to throw you an error. Specifically, Pydantic is going to throw you an error. And this is a very common pattern. And so one way to do that is one way to debug, again, is to like trigger it manually and see it on the server side. But that, again, is cumbersome. So I want to show you a neat trick. again is cumbersome so I want to show you a neat trick and the neat trick is if you go into your teams page so this is the review code and you go down to your webhooks if you click this triple dot thing you'll see this handy test in this test what it will do is it will give you sort of this playground where you can have this payload. And so there's different ways you can you can like start from. So I have this payload already from this is my the model registry that I showed you earlier. And I'm going back to this one that I already set up. And if you recall, if I view the details, I have this payload. Now, I want to share, like, when I was first creating this webhook, I kind of had to, like, think about what was being sent. And so what happens is, like, you might want to test this payload so this is the same payload and so there's there's different ways that you can try to figure out what's going on if you have an error one is to look at the logs so in modal case you can look at the logs I can see a request I can see okay there's some kind of logs now depending on your application you might not even have access to the logs like in in this case um you know these logs are not really showing me maybe what i'm looking for and i have to dig through it so it's actually helpful to see the response um you know especially if you're not using curl you want to see what the response is. And so basically, what I want to do is let's say I have this payload. And let's say I forgot to include the author, for example. And that's really easy to do is to make a silly mistake like this. It happens to everybody. And again, if I don't have the author, it's going to error because it's not having this like field and so let's test that let's test that against this modal endpoint i'm gonna go back to test webhook here and what it's going to do is um ways and biases is going to show you the response from the web server in this case what modal is is saying in this case this is a little bit what modal is saying. In this case, this is a little bit confusing because this is actually pydantic. This is like a low-level pydantic error kind of response, and it's showing you that it's missing a field. What this, like how you translate this is like you're missing this event author field. That's what this means. And this is pydantic specific. This is not anything to do with weights and biases. This is like what your web server is responding with. And it's actually really useful to see this. So if I add this back, for example, I'm going to add that field back and test the webhook. We will see that now there's a success. That there's a response and there's no error. And, you know, again, we can see that if I look at the logs, we can see that, hey, there was a success here. And then that was preceded by some errors. And, you know, in this case, actually, like, I can't really, I don't really know what those errors are, to be honest, like, I can't even see them. And this is like a real, this is kind of like a real case where having the response. So there's no error being logged on the server side. I could improve my code to log errors on the server side, but I don't do that. Like if there's an error, it just errors. It doesn't print anything. So having the response from the server actually is really useful. And it's helped me catch errors. And this has actually helped me in real life and like be able to rapidly test. And basically another way to use this is when you're actually developing your web server. Like let's say I want to continuously change this code and change the schema and change like you know the code of the web server well while you're developing it you can just like basically have two windows open where this code and sort of this testing window and keep sending payloads and sort of keep debugging and that's also very helpful so i just want to show you that this is actually like one of the most helpful things, like features to know about in webhooks is testing because it helps you develop webhooks.
Testing Webhooks
Testing is an integral part of any development process. To test and debug webhooks you can go the manual way by testing all the different triggers and checking the results or you can use the Weights & Biases automatic testing capabilities! 

Let me show you how to do it efficiently!