All Collections
New configuration interface and custom routes
New configuration interface and custom routes

Discover what's new and how it can benefit you.

Micaella Mazoni avatar
Written by Micaella Mazoni
Updated over a week ago

We have news regarding the following triggers:

  • REST

  • HTTP

  • HTTP File



Take a look at some of the most common configurations of the triggers in the previous and new version:

- Default with API Key

- With API Key and JWT

  • No security (API Key or JWT)

Understand the meaning of each field in the trigger configurations:

  • METHODS: methods of the HTTP protocol (GET, PUT, POST, PATCH and DELETE)

  • Maximum Timeout: maximum call response time

  • External API: publishes API on external gateway

  • Internal API: publishes API on  internal gateway

  • API Key: required when consuming API

  • Token JWT: required when consuming API

  • Custom URI Path: field where the custom route is inserted

With the new forms you:

  • have access to all the previous configurations 

  • can see all the configuration options

  • fill in quicker and more conveniently




Internal/External APIs exposition

Now it's possible to publish APIs by choosing external or internal exposition. See some possibilities this functionality delivers:

  • External exposition: allows the endpoints to be accessed via Internet. It's ideal for open API strategies implementation, integration with partners and external systems.

  • External exposition: publication of APIs accessible exclusively in your Realm, allows your On Premise environments to use APIs inside the Network through VPN (Private Cloud). It's ideal for integrations that involve internal systems only.


Benefits of the change

  • Greater isolation and security for integration with internal systems 

  • Possibility of external and internal versions with different functionality levels


URIs customization

The big news is in the URIs customization. Besides, the use that was external only, now is also available in your Realm.     

After the pipelines implementation, their URLs have the following structure:

  • {env}: can be the production and test environment

  • {realm}: corresponds to Realm

  • v{n}: the pipeline version

  • {pipeline-name}: name given to the pipeline

Let's say we've created the "product-list" pipeline. If we keep in mind the comment above, its URL will have this appearance:

What comes after "v1" is the custom part. In this case, we chose "product-list", that will deliver all the products of a list enabled by the company in question. Now you're free to define new routes. Here's how:

1. Activate the option "Additional API Routes".

2. Type "/products" and press ENTER.

3. Done! You have an alternative route, with a new address:

You can also add a new route that gets a parameter -  for example, "/product/:id". 

If the URL above is called, your pipeline will get the ":id" value through "queryAndPath", as the following code:

  "body": {},
  "headers": {
    "Host": "product-list:8080",
    "apikey": "xxxxxxxxxxxxxxxxxxxxxxx",
  "queryAndPath": {
    "id": "1234"
  "method": "GET"

Pay attention to your new routes definition. Conflicts inside the same Realm make it difficult to foresee which pipeline will be executed. For example:

  • A (/product)

  • B (/product)

  • C (/:product)

When different pipelines have identical URIs (as pipelines A and B), only one of them is executed. The same thing happens when the request comes with the value “product” (pipeline C). To avoid it from happening, we suggest you to adopt a naming pattern, for the requests as well.

If you use /:product (as indicated in example C), the original path to access the pipeline will be substituted. 

Let's say you create a pipeline and name it pipeline-1. As soon as it gets deployed, the platform will create the following URL:

And if you use additional routes and set the route /:message, the URL will trigger pipeline-1 considering /:message

We recommend you to be extra careful at this moment, once this route will overwrite any other pipeline that might be uploaded in version 1 (v1). Given that, for example, the pipeline would be inaccessible, because /:message would overwrite it. 

What we advise is for you to mind the creation of additional routes. If it's not entirely necessary, then we suggest you to use some prefix. For example, /my-route/:message. That way, the original URL is preserved and the other pipelines don't get harmed.

We also recommend you to follow the good REST practices. Click here to know them.

Benefits of the change

  • Greater control and security in those trigger types (REST, HTTP and HTTP File)

  • Additional routes give more flexibility to the pipelines

  • The user avoids double work if using legacies with less flexibility in terms of URI

Did this answer your question?