The Core API uses Bearer tokens to authenticate its user.

You MUST send the token for each request in the Authorization header. The token MUST be preceded by Bearer. See the Authorization header in the example request below.

curl --request GET \
  --url https://api2.frontapp.com/conversations/cnv_123/drafts
  --header 'Authorization: Bearer [REQUEST_TOKEN]'

OAuth v Front API Tokens

There are two ways to get a Bearer token — through API tokens in your settings or through an OAuth implementation.

In general, Front recommends implementing OAuth when feasible, which has the additional benefit of building within our application framework. The app framework makes it easy for customers to install your integration and makes it easy for you to update the integration with new Front features as they are added to the framework.

However, if you’re just building an integration for your own Front instance or a single Front customer, or just want to test our API endpoints as you brainstorm what to build, you can generate an API token to get up and running more quickly.

For Partners looking to launch a public integration to all Front customers, if your integration can support OAuth you’ll want to check out our OAuth guide. We require that public integrations use OAuth unless there is a reason they cannot. OAuth integrations are part of our application framework and can be easily installed by customers using the Front App Store, without requiring that customers manually configure an API token for your integration.

📘

OAuth is required for public integrations available to all Front customers unless there is a specific reason you cannot implement it. OAuth makes it much easier for customers to install your integration through our App Store.

OAuth access

One caveat to OAuth in its current state is that it only allows for the same scope: “Shared resources”, and at this time cannot request more permissive scopes. This means that integrations that use OAuth will be able to access all team resources (teams, contacts, conversations, team channels, inboxes, messages in team inboxes, team tags etc.) but won't be able to access individual teammate inboxes or settings such as personal signatures. They also do not have access to knowledge base resources at this time.

For the vast majority of integrations, the shared resources scope should suit your needs. However, if your integration needs access to private resources or to the knowledge base, you'll have to use an API token for the time being, and customers using your integration outside your company instance will have to manually configure this token for you during setup. A future update may correct this discrepancy in scopes between OAuth and API tokens to further facilitate easy installation of partner integrations that need more permissive scopes.

Check out our OAuth guide for more details.