Choose an Authentication Method
Understand how Procore's two OAuth 2.0 grant types layer together, and which ones your app needs.
Overview
Procore supports OAuth 2.0 with two grant types: Authorization Code and Client Credentials.
These grants govern how your app calls the Procore REST API, which is what Data Connector components exist for. The other capabilities do not use them. An Embedded component does not authenticate at all — the iframe loads your own web app, signed in however your product normally signs people in. An Agentic app’s MCP server signs customers in through a redirect-based flow to your system, which is not one of the grants here.
Any app that calls the Procore API declares Data Connector components and uses the grants on this page, whatever else it does. An embedded app that needs Procore data does exactly this.
They are layers, not a fork. Authorization Code is the baseline — your app declares User Level Authentication and acts on behalf of a signed-in user. Client Credentials is added on top when your app also needs to reach Procore with nobody logged in. It cannot be used on its own.
Your app has two Client ID and Client Secret pairs — one for your Developer Sandbox, and one for production, which also covers the Monthly Sandbox and On-Demand Sandboxes — and the same credentials serve both grants. There are no separate service account credentials to manage.
Authorization Code Grant
Use this when your app accesses Procore data on behalf of a specific Procore user. The user logs in to Procore, approves your app’s access, and Procore redirects back to your app with an authorization code that you exchange for an access token. Web apps in any server-side language (Ruby, Python, Node.js, Java, etc.) use this flow.
A variant covers apps that cannot open a browser, such as cron jobs, scripts, and command-line tools. Rather than redirecting, it uses a special redirect URI (urn:ietf:wg:oauth:2.0:oob) that displays the authorization code on a Procore-hosted page for the user to copy.
For implementation details and step-by-step examples, see OAuth 2.0 Authorization Code Grant Flow.
Client Credentials Grant
Add this when your app also needs to work without a signed-in user — sync jobs, report generators, backend integrations, and webhook handlers that fire when nobody is logged in.
The Procore implementation of Client Credentials uses a Developer Managed Service Account (DMSA), which carries the company- and project-level permissions your app needs. Your client credentials authenticate the app, and the DMSA’s permissions determine what the app can access.
Resolve companies and projects as the user, not as the service account. A service account’s view of what exists is not the signed-in user’s view. Use the Authorization Code grant to determine which companies and projects a person can reach, then use the service account for the background work against those resources. Choose per call rather than picking one grant for your whole integration.
For implementation details, see OAuth 2.0 Client Credentials Grant. For DMSA setup, see Developer Managed Service Accounts (DMSA).
Decision Tree
Still unsure after reading both grants? Match your scenario to the right one in the matrix below.
| Your scenario | Use this | Implementation guide |
|---|---|---|
| Your app acts only on behalf of a signed-in Procore user | Authorization Code grant | OAuth 2.0 Authorization Code Grant Flow |
| Your app has no browser and acts on behalf of a signed-in user | Authorization Code grant — Installed-App variant | Installed-App Variant |
| Your app also runs unattended — sync jobs, overnight webhook handlers | Authorization Code grant, plus Client Credentials through a DMSA | OAuth 2.0 Client Credentials Grant + Developer Managed Service Accounts (DMSA) |
See Also
- Build a Data Connector App — declare these components on an app version.
- Developer Managed Service Accounts (DMSA) — permissions, and how they behave across app updates.
- Choose an App Type — the capabilities you can combine in one app.