API Triggers are specialized HTTP Triggers bound to a Swagger/OpenAPI Specification operation. API Triggers can only be created through API Management and share configuration with HTTP Triggers to a large extent.
​

The HTTP method is locked to that provided in the Swagger operation and cannot be changed. Valid values are GET, POST, PUT, DELETE, HEAD, OPTIONS, and PATCH.

The URL path is locked to that provided in the Swagger operation and cannot be changed. Path parameters are allowed. If the path parameters are of type integer or boolean, then the path will be restricted to containing only those types.

This enables having endpoints like /api/pet/{id} and /api/pet/getStatus active at the same time with no collision, if the {id} parameter is of type integer. However, having /api/pet/{name} and /api/pet/getStatus at the same time would not be possible if the {name} parameter would be of type string.

API Triggers can be configured to accept requests with HTTP, HTTPS, or both. If a request is made with a protocol that is not allowed, the reply will be Forbidden (403).

API Triggers can use four different kinds of authentication:

We strongly recommend only using authentication over HTTPS.

API key authentication uses an API key together with a Ruleset to determine if the client has access to a URL. For more information, see API keys.

OAuth2 uses OAuth bearer tokens from registered OAuth applications to gain access to the API. You need to set an API Access Policy to allow access.
If you are using scopes for controlling access to an API, you need to give the required scopes in the Swagger definition. Please note that if you give many scopes to an API Trigger operation, calls will go through if the OAuth token has any of the scopes given.

Basic authentication requires, in a typical setup, authentication to be built into the Process. Authentication might also happen either against the Active Directory or the local users. Which one is used depends on the Frends Agent service user. If the Agent uses a local user account, users are authenticated against the local machine users. If the Agent uses an AD user account, users are authenticated against the AD users. The username and password need to be encoded with UTF-8 before being converted to Base64 for the basic authentication header.

If there is a need to allow a certain page to trigger a Process, it is possible to do with cross-origin resource sharing (CORS). Check the "Allow requests from these origins" checkbox, and define the allowed origins in the textbox. The * character allows calls from all origins. Multiple origins can be provided separated with a colon(,) or semicolon(;).

Note: If the call does not come from the default port, it must be included in the origin. The origin making the call must also support CORS.

A read-only display of the swagger operation bound to the Trigger. 

To enable this feature, you will need to use OpenAPI Specification 3.0 instead of Swagger 2.0. See here for information on how to create a request body specification that allows passing request content as Base64-encoded bytes.
For now, we only support simple file upload. In this case, the HTTP message body will be left unparsed. Instead, the request will be passed as-is, as a byte array (serialized as a Base64 string) accessible via the #trigger.data.httpContentBytesInBase64 reference.

You can try to access an optional reference from any of the references (e.g. #trigger.data.httpHeader.foo), and if it is found, the value will be returned, and if not, the value will be set to null.

Swagger parameters usually contain a type definition. Parameters of type integer, number or boolean will be cast to their corresponding .NET type (Int, Long, Float, Double or Boolean). For array type parameters, the array will use the separator defined in the Swagger parameter and the array content in turn will be cast according to their types. An array parameter with a csv separator and content type integer has the call content "1,2,3,4,5" and will be accessible as an JArray containing integer values.

A Process can return a response for the user before the Process is finished. This functionality is enabled by adding an intermediate result Element to the Process. When this Element is executed, the caller will receive an HTTP response from the Process. This can, for example, be used when calling a long-running Process, and the caller should be notified that the long-running task has started.

The API Trigger returns the result of the executed Process as the HTTP response. The response varies according to the following conditions. When the Process's result is a string, the string is set as the body of the response. If it was an object, it will be returned either as JSON or XML, depending on the request's ACCEPT header, or JSON by default.

For example, ACCEPT: application/xml would produce an XML response, while ACCEPT: application/json would produce a JSON response.

If the result is an object with the properties HttpStatusCode and Content, the result will be mapped to a response as follows:

The Process Elements Return, Intermediate Return, and Throw all have the option to generate a predefined HTTP response.

See HTTP response results in the Parameter Editor.