My API Question

What are the options for altering the request URL in My API dependent on the endpoint?

For example, I would love to be able to do the following, but not sure if its possible:

Base URL:
https://api.integrator.io/v1/apis/123ABC/request

Can I do this?
https://api.integrator.io/v1/apis/123ABC/request/health
https://api.integrator.io/v1/apis/123ABC/request/invoices
https://api.integrator.io/v1/apis/123ABC/request/payables
https://api.integrator.io/v1/apis/123ABC/request/cashreceipts

I don't believe I can do this since the base URL cannot be altered, but wanted to make sure.

Hi @daveguderian .... the options you have are:

  • 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.

2 Likes

Perfect! Can't wait for the upcoming March release!

Thanks @tonycurcio

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.

4 Likes

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?

Thanks again and great work on this!

Hi Dave,

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?

Hi Kathyana-

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).

Does that make sense?

Hi Dave,

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!

1 Like

Hi Dave,

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.

This is a sample API I have used to test this scenario:

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.

When I don't pass the query param in the API request, I get the error

and when I add the query param, it is successful

Hope this helps!

Thanks,
Kaustav

Thanks @kaustavroy. This is very helpful.

Is there an ETA on when this will be available in the transformation layer that you mentioned?

Thanks @daveguderian. It will be available soon but the release is not confirmed yet. We'll let you know as soon as it's confirmed.

1 Like

Sounds good! Thanks @kaustavroy & @tonycurcio!

On a sidenote, I'll be using response code 418 for all failures moving foreward! :rofl:

3 Likes