HTTP Trigger
Discover more about the HTTP Trigger and how to use it on the Digibee Integration Platform.
Last updated
Was this helpful?
Discover more about the HTTP Trigger and how to use it on the Digibee Integration Platform.
Last updated
Was this helpful?
When a pipeline is configured and published with HTTP Trigger, an HTTP endpoint is automatically created. You can visualize this endpoint after the implantation - all you have to do is click on the pipeline card in the Run screen.
With this trigger, you have the flexibility to define different content types not only for the request, but also for the endpoint response.
Take a look at the configuration parameters of the trigger. Parameters supported by are marked with (DB).
Methods
Configured the HTTP verbs to be supported by the endpoint after the implantation.
POST, PUT, GET, PATCH, DELETE, and OPTIONS
String
Request Content Types
Determines the content types the endpoint can receive.
text/xml, application/xml and application/x-www-form-urlencoded
String
Response Content Types (DB)
Content types to be returned by the endpoint when the pipeline processing ends. This parameter can't be left blank (the response depends on the treatment with mock + Double Braces).
text/xml, application/xml
String
Response Headers (DB)
Headers to be returned by the endpoint when processing in the pipeline is complete.
This parameter cannot be left empty and accepts Double Braces. Special characters should not be used in keys, due to possible failures in proxies and gateways.
N/A
Key-Value Pairs
Add Cross-Origin Resource Sharing (CORS) - CORS Headers
Add the CORS headers to be returned by the endpoint when processing in the pipeline is complete. This parameter defines CORS specifically for the pipeline and its constraints.
N/A
Key-Value Pairs
Maximum Timeout
Maximum time that the pipeline takes to process information before returning a response. Limit: 900000. In milliseconds.
If the processing takes longer than the parameter definition, the request is finished and returns status-code 500, but but without a body.
30000
Integer
Maximum Request Size
Maximum payload size (in MB). The maximum limit of the configurable payload is 5MB.
5
Integer
External API
If the option is enabled, the API is published in an external gateway.
True
Boolean
Internal API
If the option is enabled, the API is published in an internal gateway. The pipeline can have both the External API and the Internal API options enabled simultaneously.
False
Boolean
mTLS enabled API
If the option is activated, the API is published to a gateway dedicated to APIs with mTLS enabled by default. In this case, the access host will be different from the others. The pipeline can have both the External API and Internal API options enabled at the same time, but it is recommended to leave them inactive.
False
Boolean
API Key
If the option is activated, the endpoint can be consumed only if an API key is previously configured in the Digibee Integration Platform.
False
Boolean
Token JWT
False
Boolean
Basic Auth
If the option is activated, the endpoint can only be consumed if a Basic Auth setting is present in the request. This setting can be registered beforehand through the Consumers page in the Digibee Integration Platform.
False
Boolean
Additional API Routes
If the option is enabled, the trigger allows you to configure new routes. See more about this parameter in the below.
False
Boolean
Remove Digibee Prefix from Route
False
Boolean
Routes
Displayed only when the Additional API Routes parameter is enabled. Here you can define the endpoint additional routes.
N/A
String
Rate Limit
False
Boolean
Limit by
Defines the entity to which the limits will be applied.
API
String
Aggregate by
Defines the entity for aggregating the limits. Options: Consumer and Credential (API Key, Basic Auth).
Consumer
String
Options
Defines the limit of requests that can be made within a time interval.
N/A
Options for limit and interval
Interval
Defines the time interval for the limit of requests. Options: second, minute, hour, day, and month.
second
String
Limit
Defines the maximum number of requests that users can make in the specified time interval.
N/A
Integer
Allow Redelivery Of Messages
False
Boolean
(DB)We use a comma to enter multiple values in a header, but we don't add a space before or after the comma. Special characters should not be used in keys, due to possible failures in proxies and gateways.
If the payload sent by the endpoint consumer overcomes the limit, a message will be returned informing that the maximum size has been overcome and a status-code 413 with the following message:
This parameter does not support API Key, JWT, or Basic Auth. To use it in your realm, it is necessary to make a request via chat and we will send you the necessary information to install this service.
As previously explained, this option is for the configurations of new endpoint routes.
When deploying a pipeline, a URL is automatically created. However, you can customize the route according to your convenience. It also includes the parameters received through the route.
After the pipelines are deployed, the URLs will get the following structure:
TEST:
or PROD:
{realm}: corresponds to realm.
v{n}: pipeline's major version.
{pipeline-name}: name given to the pipeline.
Let’s say you’ve created the product-list pipeline. Considering the comment above, your URL would look like this:
Now, see how to configure a static route for this case.
With the configurations applied and the pipeline deployed, you will get a new URL:
Using the same example of the previously configured pipeline, see how to custom the route:
With the configurations applied and the pipeline deployed, you will get a new URL:
In this case, the endpoint consumer can send a request containing the id of a product and return information only about it. Example of the request URL:
To use this value sent by the route inside the pipeline, go for the Double Braces syntax:
As previously explained, this option is recommended for removing the default Digibee route prefix from pipeline route.
Let’s say you’ve created a pipeline and set the trigger as follows:
With the configurations applied and the pipeline deployed, you will get a new URL:
When creating APIs, we usually want to limit the number of API requests users can make in a given time interval.
This action can be performed by activating the Rate Limit option and applying the following settings:
If the API has additional paths, the limit is shared among all paths. To apply the rate limit settings, the API must be configured with an API key or Basic Auth so that the Aggregate by parameter can be used by groups of credentials if the Consumer option is selected, or by an individual credential if the Credential (API Key, Basic Auth) option is selected.
If multiple interval parameters are configured with repeating values, only one of these values is considered. It’s also necessary that a value greater than zero be informed for the Limit parameter.
If the rate limiting options aren't set correctly, they'll be ignored and a warning log will be issued. You can view this log on the Pipeline Logs page.
See below how the trigger behaves in a determined situation and what its respective configuration is.
Check how to configure a pipeline with HTTP Trigger to return information from inside the pipeline in XML format and how the response must be handled specifically for this trigger.
First of all, create a new pipeline and configure the trigger. The configuration can be made as follows:
With the configurations above, you set that:
the endpoint works with the verb GET only;
the request accepts content-type related to the XML only;
the response returns content-type related to the XML only.
Besides, you determine that the API is external and doesn’t need a token for the communication.
After that, the last step is to set and determine how the response of this information will be made to the consumer. Add a MOCK again, given that its function will be to set the response only. Connect it to the JSON To XML Transformer output.
To configure this MOCK, use the following JSON:
code: HTTP Status Code to be returned by the endpoint after a request is finished
Content-type: content type of the response body. All the types are supported, but must be declared in the Response Content Types field.
When done with all these configurations, you should have a pipeline that looks like the image below:
After the deployment, get the generated url and send a GET-type request. The endpoint must return the status-code 200, as previously shown, and the response body should look like this:
Whenever you want to make a request to the created endpoint, the structure of the message the trigger delivers to the pipeline is always the same and follows this pattern:
body: content to be sent in the request payload to be transformed into a string in this field.
form: if the form-data is used in the request, the sent data is delivered in this field.
headers: the headers sent in the request are delivered in this field, but some of them are automatically filled with the tool used to make the request.
queryAndPath: the query and path parameters provided in the URL are delivered in this field.
method: HTTP method used in the request to be delivered in this field.
contentType: when informed in the request, the Content-type value is repassed to the pipeline inside this field.
path: the path used in the URL in the request is repassed to this field.
If the option is activated, the endpoint can be consumed only if a JWT token previously generated by another endpoint with this capacity is sent. Read the article of the to have more details.
This option is available only when External API and Internal API parameters are disabled, and mTLS enabled API and Additional API Routes parameters are enabled. Set this option to remove the default Digibee route prefix "/pipeline/{realm}/v{n}" from the pipeline route. See more about this parameter in the below.
If the option is activated, a rate limiting configuration will be applied on the API gateway. This option is only available if API Key or Basic Auth is active. See more about the Rate Limit parameter in the below.
If the option is enabled, it allows the message to be resent in case the Pipeline Engine fails. Read the article about the to have more details.
Cross-Origin Resource Sharing (CORS) is a mechanism that lets you tell the browser which origins are allowed to make requests. To configure globally rather than individually on each pipeline see the .
Now observe how to configure a in the pipeline so it becomes the data provider the endpoint returns in the end. Add the indicated component, connect it to the trigger and configure it with the following JSON:
The next step is to add a component that transforms the previously created JSON into a XML pattern. For that, use , add it to the canvas and connect it to the JSON Generator that was previously added. Keep the following configuration:
body: response message body (Double Braces are being used to repass the information converted in the previous step). This item must necessarily be a string. If the data you want to send is a JSON, use the function.
