add Celigo API Management: that would allow you full control over the endpoints as well as extend the set of authentication types and governance policies
upcoming API Builder: covered in our March release notes you will have control over the endpoint naming (it works with the base URL differently). The full set of doc for that will be coming out in the next day or so and then it will be in product shortly thereafter.
Hi @daveguderian - the low code API builder is live now. It is accessible by account owner and admins with developer mode option enabled. Also, here's the doc link which talks about configuring the relative URI for the API.
Thank you so much Kaustav! I have built several calls already and am finding the new functionality intuitive and easy to use.
One question I did have was around error handling. Lets say for a GET request where a couple of identifiers are required in the call (lets say zip code and account number).
What would be the best way to handle erroring if the GET request didnt contain one of these fields? For example maybe I sent the account number but left the zip code blank in the GET call. Can I return a custom error message like "Zip code is a required field"? Would I have to build branches for each possible error, or could I configure the listener to check for these data points before sending through the rest of the flow?
You can return custom errors in API builder. I'm not sure if you can configure the listener to check for those data points, but I'm sure @kaustavroy can chime in here. Is there a reason you wouldn't want to build a response picker branch for the error?
I will have a response picker in the flow, but wanted a quicker way to return an error if basic information wasn't submitted in the original request (i.e. zip code was missing).
That makes sense! Unfortunately, I don't have a clear answer for you, but I'm sure Kaustav can clarify. Some errors, such as 400 (Bad Request), 401 (Unauthorized), 404 (Not Found), 413 (Payload Too Large), and 415 (Unsupported Media Type), are returned to the API consumer even before the API starts running. I'm unsure if any of these would be returned for missing information.
@daveguderian We do have a list of the common error codes and none include missing information, but this is a scenario I'm not sure about. I'm sure Kaustav will be able to help!
To validate the incoming request you can add a custom script in the input filter of the first downstream step, as shown below. Ideally it's best to add the validation at the Transformation step in the API request node, but that's not supported yet, and is planned for an upcoming release.
Here's the API request configuration, which has 3 query params, out of which there's validation added for itemid and status in the input filter step (mentioned above).
And, in the error response node, you can configure the status as 400 - Bad Request, or any other code of your choice. You may also customize the error response body if needed.
