Return Any Status Code You Want in Xano (@noodebackend)

Ray Deck shows how to return any HTTP status code from Xano endpoints, not just the built-in ones. He uses the HTTP header utility with a string-replace filter to inject custom codes like 409 into the response header, then validates it with curl and browser DevTools.
Chapters
Hey, this was a really interesting question coming off the Xano community, which was about how to have a completely custom HTTP response code in Xano. And the essence of the problem is if I were to go to, say, my Xano for a second, and I were to just, let's create a a new endpoint. Let's go API and just pick one of my groups and I'll create a raw endpoint. I'll just start from scratch. I'll call it test status code. And if I were to want it, usually what I would, if I were to just run this, say from a browser over here, like I'm just going to go grab the endpoint URL and we paste it into here. Immediately get no particular response. Now, if I were to go open up DevTools for a second and take a look at the, the data that came over the network, I just sort of refresh this. You'll see it shows up with this 200 error over here. And if I were to open this up, it would tell me that my response code was nice green. It was a 200, which usually means success. And that's an HTTP thing. Like the codes are usually 200 or 200-something means successful. 300-something means you're supposed to go somewhere else. 400-something means usually an error with the request and a 500 usually means an error that was somewhere on the server side. And then there, there are other errors as well, but those are the ones you see most often. And basically you're looking for a 200. 200 means happy times. And Xano knows this and usually will want to return 200 and it provides you with this function in here, a utility function called precondition that allows you to like establish a situation in which there was something went wrong and you can say something went wrong and it's going to be a standard error. And let's just make that all backwards. It's only, it will return an error only when this thing is false. So basically, you, the precondition means that if you run the test and it passes the test, it keeps running. And if it fails the test, then it fails. And in my case, it's just, I'm going to say that, okay, if true equals false, which will always be false, then publish. And if I were to refresh this guy here, You'll see down here it shows up, it's test code and comes back with this 500 error. So if I were to go into here, the type of error it was asking for was standard error. If instead I ask for a not found error, that's usually an HTTP 404. And if I just do a quick publish on that, publish, publish, I can, you know, clear this and then refresh. And indeed it comes back with a 404 error, right? So like the, these preconditions make it sort of easy to set up standard error messages and standard error types that we associate with our, with, with things might go wrong in the webpage, right? So the standard is the 500. That means something freaked out on the server. 404 means not found. Access denied. I think that's a 401. Too many requests. I think that's a 429. Unauthorized. I think that's a 403. And a bad request, that's a 400. But that's not the entire possible universe of potential errors we want to send back. And this brings us back to the question that came from Xano community, which is you want to send back a 409. You can do that. And the way that you would do that is instead of using the preconditions, as cool as they are, you would just probably compose for yourself. And I'm just gonna comment out the precondition here for a second. Just say, don't worry about it. We use this little winky thing and then sometimes we remove our connection because Xano does that to me. Okay. We can wink out the, the previous precondition we're using. We know how to do it the standard way, but that's not the interesting way for us. We want to focus on the question, how can we get a 409 response specifically? The way we do that is a little bit counterintuitive. We need to replace the HTTP header. That's like the first thing that comes back from when we do a browser request. So if I were to go in here to the status, to this code, it breaks it down for me. But you can also usually see the, the raw version of this if we wanted to. If I were to take this URL here and if I were to bring it to a terminal and I were to run curl with it instead, so much more low-level view, and I were to paste this in, it would also say, hey, there's an error. But if I were to do this with a -v, it'll tell me about all the headers that came across. And one of them here says HTTP/2/404. And that's how it tells me that it's missing something. Is going to be through this what's called an HTTP header. Now I need to go back over to my thing here and I can, using utility functions, go to where it says HTTP header here and I can set a custom header. I know this thing should be saying HTTP/2 and the, we know that because of what this thing says here. And now we want to say what the code is that comes after that. So I'm gonna say after that code, I'll explain why I'm doing this in a second. And then after that, usually I should go to the message that will go along with that guy too. So now we need to figure out what the code and what the message are going to be. So I'm just going to quickly set up here a variable, which is going to create a variable, and I'm going to say this is called code, and the value is just going to be a 409, exactly what this person wants. Great, it's 409, save. And the, and I'm also going to set up a message, which is going to be a create variable, call it message., and that variable's going to be, okay, duplicate. That way I just have a little message that'll go along with it too. And now inside my header, where I can say, which I didn't save, I guess. So HTTP/2 code message. And this is how I like to do string replacement. And so I will do a filter here. I will say choose filter and I'll choose replace. Replace. And the search is going to be for the all text, all caps code that I put in there before. And I'm gonna replace it with the code variable that I just created. Then I'm gonna do the same thing for the message. So we can do a replace for MESSAGE, all caps, and replace it with the variable I just created called message. Update. Save. Now, the cool thing about doing it with variables makes it really easy for me to change, as I'll illustrate in just a minute. So the, so now I've set this particular header, and remember, anytime I want to test this, because I'm testing headers, I need to publish it. Fine. And now I'm going to go back over to this other tab where I just was keeping on looking at test status code, and I'm going to refresh it here. Now it gives me back a null, didn't have anything interesting to say. Down here it says test status code, and it has that 409 over here. That's exactly the code we wanted. And the, if I wanted to look at it in greater detail, I could take a look at it through the curl like we have over here, and I could run that again. And you'll see as HTTP/2 409. Again, it didn't actually put in the message, which I'm a little confused about. So message was duplicate, fine. It seems like it did correctly put in the, the code, but it doesn't currently put in the message in HTTP/2 and whatever. The most important thing here is the code came back, which means that like the browser will see it as a correct type of thing, which will make this person's front-end code or the counterparty to the particular API call know that in fact the reason why it's being rejected is because of duplicate. And if I want to use some other code, that's actually really straightforward. All I need to do is change this code here to, if I wanted to be 4, just get the 411 on that. I don't actually know what a 401 error code is, if it's anything at all. And I can scroll up, say publish, publish, relaunch. We'll just clear it out so it's easy to see at the top here. And we'll refresh the page and it comes back with 411. So this shows you how you can now wire up your own precondition. So instead of using precondition the same way it was, you could actually compose a precondition to create any kind of custom header response you want. All you need to do is say, is compose this together with a conditional, right? And that conditional is just like the one I just, for if true is, except of course you It would only, you know, if true is false. And so if true is equal to false, and then I'll just say else. Remember, because the way the conditional, the preconditions usually work is if it's true, it's fine. It's only if it fails that it will do your thing. And in that case, I've just dragged all these things into my else and set the header. And then I do one more thing. I would just tell it to return early, which I can do through utility functions, and I can return a result and just tell it to return, I don't know, have it return whatever the message was, right? That keeps it simple. And of course you can make this into whatever you want. But now instead of like the one-liner for the precondition, which works for those 5 specific codes, you can use this composed up if plus setting the header and doing a quick return to have it always, to have it only create the exact code that you want. And so if I were to do publish here and publish, great. And I were to do Ray Launch again, I could do refresh. Ooh, it says missing conditional statements. Oh, because I apparently didn't save that there. All right, let's fix that. So if I just say true, false, So if true is equal to false, which of course is never gonna be true, therefore I'll never hit the then, I'll always hit the else. I can just hit publish and publish. Okay, so what we're going to do here is we're gonna set the return to be of the message. Save that. Return to the message and we'll say save. See the return is a message. Good. And we'll say publish. And then we'll go to relaunch and refresh this particular page. And now you can see how it comes back with the, the, the string, right? Which is the fact, the reason why it failed. And it also gives me down here the 411, which is the error code I was looking for. And all I need to do is just make changes here. And I now have a composed up alternative precondition that can create any kind of error code and error message that would be useful for whatever my counterparties are, whether it be my front end, whether it be another machine, whatever it is that's working with my Xano backend, because you can control your status code entirely. Doing this kind of, you know, deep cut stuff can actually be really important when you're trying to compose APIs together. And it is a thing that we, you know, talk about often that we're working on the harder parts of no-code over a state change. So this is a fun one to work on, and I hope it's very helpful to this individual over at the Xano forum.










