How to create application requests

Application requests allow admins to build workflows that can retrieve data, send data, and take action in third-party systems.

Application requests are part of Front’s “Connectors” framework (composed of both application objects and application requests) - allowing you to configure how your third-party data is used in Front. See our developer documentation for additional details.

More resources:

• Take a Front Academy course here to learn more about how Connectors work.

• Have questions? Ask them in our AMA in Front Community!

If you want to set up automation for your agents to get information from or take action in a third-party, an application request can be used in a rule or macro to fetch, create, update, or delete third-party data.

This means that you may be able to cancel an order, update shipping information, change the status of a ticket, and more in other applications you work with from within the Front interface.

You must be a Front company admin to create application requests.

Step 0 (create an app)

You can access your Developer settings by clicking the gear icon in the top right of Front, then selecting the Developers tab from the left sidebar.

Once in Developers settings, click the Create app button. You’ll be asked to provide a name for your app and a short description. If you'd like to set an icon to be used for your application objects, simply add an icon to the app you initially created by going to the Basic information tab of the app.

Once you’ve created your app, click the Features tab and then click See all connectors under the “Connectors” card. You’ll be navigated to a page that has two tabs, Application objects and Application requests. Click Application requests, then Configure application request to create a new one.

Step 1

First, you will be asked to provide a name and a short description for your object.

Step 2

Next, you will need to define the variables required to send the application request. These will be defined by the action you are wanting to take in your third-party application within the third-party’s documentation.

Step 3

Next, you will need to tell the application object where to get data from or send an update to.

Select the method of the request: GET, POST, PUT, PATCH, or DELETE. 

Then select the URL. If you have already connected to a server, select it from the dropdown and skip ahead to Step 4 below. Otherwise, click New server.

Set the Origin field to the URL origin of your API. Don't worry about the particular API endpoint you'll be using yet — this field should just include the origin. For example, if the API endpoint you want to use is https://{your-development-store}.myshopify.com/admin/api/2024-07/orders/{order-id}/cancel.json, the origin would be https://{your-development-store}.myshopify.com/

Set the Authentication strategy used by your API. Today, API Key, Basic, Bearer, and OAuth2 authentication are supported. Depending on the strategy you select, you may be asked to provide additional configuration fields. Then, click Connect.

Step 4

Fill the path to complete the URL by entering the path of the API endpoint you want to use, with any relevant variables filled in using variables from the original text pattern of your application object. 

For example, let's imagine we wanted to use Shopify's Cancel an order endpoint: https://{your-development-store}.myshopify.com/admin/api/2024-07/orders/{order-id}/cancel.json

The order id would be pulled from the inputs defined in Step 2. Therefore, we’d configure the path as follows:

Note that the dynamic portion of the URL (“order id”) comes from the order id variable we created in the Create inputs step (in Step 2 above).

In order to move to the next step, you need to test your request by entering a matching reference and clicking Test request. Please note that this will execute the request if it is working correctly. You may consider testing the connection with a test environment in your third-party app to avoid canceling an order, updating a record, or any action you are testing.

In our example using Shopify, we’ll receive a response like this:

Step 5

Next, define your outputs. This is most relevant for GET requests but you will need to define fields for all request types. 

Determine what data you want to extract from the response with dynamic variables and map them to a display name so that it’s easy for your end-user to consume the information. Create a new dynamic variable to extract it from the response received from the API.

For example, to extract the "canceled at" from our example above as its own variable, click Create new in the dynamic variables manager, then Start dynamic variable path and then Response. This will allow us to use the value of the value we extracted in Step 4. Next, we'll configure the time canceled variable as follows:

Note that the "time canceled" object property is nested under "order". We also added a step to "Parse as string" since we know that this property will be a string.

Step 6

Once you've set up your dynamic variables, they can be inserted into the application object's properties using the "+" button.

In our example, since we extracted the “canceled time” from the Shopify API, we can now insert it into the request’s output:

Step 6

Finally, click Next to test your application request configuration. If properly configured, you should see the data from your API enriched on the application object:

Once an application request has been created for an application, a rule or macro is required to activate a request.

Step 1

To create a rule with an app request, first follow How to create a rule from scratch.

Step 2

Enter your preferred rule configuration for when you want the request to activate and under what conditions. Like other rules, you can define the triggers (when), conditions (if) and actions (then) of your rule. See this article to learn more.

Step 3 

For POST, PUT, PATCH, or DELETE request methods

Once you have configured your triggers and conditions, select the Send app request action from the dropdown, then select the application request that you want the rule to execute.

You will notice that after you select the application request, the input fields that were defined during the creation of the request will be shown. This is where you will add the input variable that will be sent with the request.

You will likely need to define a dynamic variable here that will pull information from the conversation message, from an associated application object, from a contact, etc.

Once you save, your rule will apply to the workspace the rule was created in.

For GET requests

GET requests can be used in dynamic variables leveraged by a rule’s condition(s), when you want a rule to take action dependent on information in your third-party application, or a rule’s action, when you want a rule to take action in your third-party application.

To use an application request in a dynamic variable leveraged by a rule’s condition(s), set your condition to Dynamic variable is, select New dynamic variable, click the Create new button on the right pop-out, choose your application request from the dropdown, and add steps as necessary.

Step 1

To create a macro with an app request, first create a macro using the steps here.

Step 2

In the flow builder, navigate to your Apply actions step and click + Add action.

Step 3

Click + Add action, then select Send app request.

Step 4

Use the dropdown to select your app request. You will notice that after you select the application request, the input fields that were defined during the creation of the request will be shown. This is where you will add the input variable that will be sent with the request.

You will likely need to define a dynamic variable here that will pull information from the conversation message, from an associated application object, from a contact, etc.

If needed, continue adding additional actions.

Step 5

Click Done to confirm the actions you’d like your macro to take. Click Create to finish the macro. 

To review how to trigger macros, see this article.

Application requests are available on the Scale plan or above.