Skip to main content

What is a Service Account?

 Sunset of Traditional Service Accounts

All Traditional Service Accounts will sunset on December 31, 2024.

Traditional Service Accounts were deprecated on December 9, 2021. Beginning October 1, 2024, we will no longer allow the creation of new Traditional Service Accounts. Existing Traditional Service Accounts will continue to function until December 31, 2024.

In accordance with this timeline, developers of data connection applications that currently use Traditional Service Accounts are required to update their applications to use Developer Managed Service Accounts, and customers will be required to install these updated applications before the sunset date. All data connection applications not migrated by the sunset date will cease to function. Any application listed on the Procore App Marketplace that is not using a supported method for accessing the Procore API will be removed by the sunset date. See Migrating Data Connection Applications to Use DMSAs for additional information.

 Service accounts allow you to support integrations that require the Client Credentials grant flow as defined in the IETF OAuth 2.0 Framework Specification. In this scenario, applications need a way to retrieve an OAuth 2.0 access token outside the context of any specific Procore user. OAuth 2.0 provides the Client Credentials grant type for this purpose. A unique client_id and client_secret is generated when a new service account is created. For information on implementing the Client Credentials grant flow in an application, see OAuth 2.0 Using Client Credentials on our Developer Portal.

Service accounts do not act on behalf of an existing Procore user, but rather they utilize a Directory contact that is generated automatically upon creation of the service account. Service account permissions and access are controlled by the permissions settings for the Directory contact. By default, upon initial creation a service account will have no permissions ('None') to view any data within the company it is created in. Procore administrators must manually specify elevated permissions to the service account in order for it to have access to more data. See Configure Service Account Permissions for additional information.

 Things to Consider
  • A service account has an auto-generated email address which is inaccessible and cannot be used to set a password or log in to the Procore web/mobile applications.
  • The Directory contact associated with a service account must not be added to any other company directory aside from the one it was originally created in. Doing so will render the service account non-functional.
  • After a service account is created, the associated default email address must not be changed. Doing so will render the service account non-functional.
  • Resetting the client secret will reset all permissions and project memberships for the selected service account.