Create application objects with third-party data


Note: This article focuses on use cases involving application objects and third-party data (application requests). If you're just getting started with application objects, please review the general application objects article first.


Application objects allow you to transform text or URLs found in comments or messages into structured Orders, Shipments, Itineraries, Tasks etc. that are easy to access right from a conversation in Front.

That core functionality is available on the latest Growth plan and above, but customers on the Scale plan or above can use application requests to populate an application object's custom fields with data pulled from a third-party application.

When to use third-party data

A few examples where application objects with third-party data are useful:

  • You want to see metadata about the objects you're dealing with, directly within Front. For example, the expected arrival date of a shipment, the completion status of a task, or the teammate that owns an itinerary could be synced onto the application object and visible from Front without opening any external tools.

  • You want to use object metadata to power rules in Front. For example, routing conversations to a particular teammate depending on the owner of an associated load in your CRM.

  • You want to use object metadata to generate a useful target URL for your application object. This is sometimes needed if the matched text or URL pattern is not enough to generate a useful target URL.

Application objects make these use cases possible without writing any API code or hosting your own server, so long as you have access to an API that allows you to retrieve the data you're looking for.


Creating a Server

At a high level, application objects with third-party data work by allowing you to connect Front with an external API to fetch relevant data for your objects. Using Front's Application Servers feature, no code or self-hosting is required.

Step 1

After you've created an app, select the Servers tab and then click Create server.

Step 2

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{baseId}/{tableIdOrName}/{recordId}, the origin would be

Step 3

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. Finally, click Create.

Step 4

After creating the Server, open it once more to set the Local credentials. These credentials should be the ones that allow you to connect to the third-party API. For example, if you selected API Key as the Authentication strategy in Step 3, you would save the particular token you use to access the API in Local credentials.

That's it! Your Server is now ready to make API requests. 

Using your Server to enrich application object metadata

The following steps assume you already have an application object set up. If you haven't, follow the instructions in the general application objects article.

Step 1

On the application object configuration page, click on the Build request step.

Step 2

Select the server you just created and enter 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 Airtable's Get record endpoint:{baseId}/{tableIdOrName}/{recordId}.

The base ID and table ID would be static for all of our application objects, but the record ID would be pulled from the text pattern. Therefore, we'd configure the path as follows:

Note that "appti123" and "tbl23" are set statically, whereas the dynamic portion of the URL ("DIGITS1") comes from the Digits variable we created in the Text pattern field from the Create reference step.

When a matching text pattern is identified by the application object, Front will send a GET request to the server and path specified using the Local credentials you previously configured.

In order to move to the next step, you need to test your request by entering a matching reference and clicking Test request. In our example using Airtable, we'll receive a response looking like this:

  "createdTime": "2022-09-12T21:03:48.000Z",
  "fields": {
    "Expected arrival date": "4/13/2023",
    "Name": "Engine",
    "Team": "Red Bull"
  "id": "rec123"

Step 3

For each piece of metadata you want to add to your object, create a new dynamic variable to extract it from the response received from the API.

For example, to extract the "Expected arrival date" 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 2. Next, we'll configure the arrival date variable as follows:

Note that the "Expected arrival date" object property is nested under "fields". We also added a step to "Parse as string" since we know that this property will be a string.

Step 4

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 “Arrival date” from the Airtable API, we can now insert it into the object's custom field:

Step 5

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

Additional tutorials

Check out these step-by-step walkthroughs to continue exploring how to set up application objects to retrieve data via an API:

Application objects and rules

Once you've configured an application object with third-party data that syncs metadata onto your objects, you can use that metadata in Smart Rules by creating conditions that check against the objects attached to the conversation.

For more details, check out our articles on Smart Rule variables and How to build a Smart Rule.


When is metadata for a particular object updated/refreshed?

Metadata will be refreshed for a particular object each time its reference is found in a message or comment, or when used in a rule’s dynamic variable.

This means that it is possible for information to be out of date if data changes in your CRM for a particular record after an application object is created for that record in Front. To guarantee that the information is up to date, you can manually send an API request with the reference of the object using


Application objects connected to third-party data are available on the Scale plan or above.