Getting Started with BetterUp’s Partner API – BetterUp

API reference

The full endpoint list, permissions, and a try-it console live at api.betterup.co/docs.

What the Partner API is for

The BetterUp Partner API lets your systems talk to BetterUp directly. Your integration authenticates as a service, using a client ID and secret in place of a username and password (OAuth 2.0 client credentials - the standard approach for system-to-system access).

Connected systems can read, and with the right permissions write, your org structure, accounts, entitlements, and reporting data.

Example we’ll use throughout this guide: a key scoped to read-only reporting access, so your dashboard pulls engagement data on a schedule instead of someone exporting a CSV every quarter. The same pattern (one key, narrowly scoped, one integration) applies to whatever you connect next.

Before you begin

You need two things:

The Manage API Keys permission in Partner Hub. View API Keys only lets you see existing keys, not create or revoke one.
Self-service API credentials enabled for your organization - on by default for most partners.

Don’t see “API Credentials” under Settings?

It isn’t enabled for your organization yet. Contact your Customer Success Manager or Support to turn it on, or to have a key issued for you.

Generate a key

From In the People Analytics DashboardPartner Hub:

Open API Credentials: Settings → System and Security → API Credentials or click the link here.
Select Add: Only visible with the Manage API Keys permission.
Name it: Something that identifies the integration, e.g. “Engagement dashboard — production.” Use one key per integration.
Set an expiration (recommended): Limits how long a leaked key stays useful.
Select permissions: Only what’s needed — a dashboard typically needs read-only reporting. You can’t grant more than your own role has.
Select Create: BetterUp shows the client ID and secret once.
Copy both now: Into your secrets manager. The secret can’t be shown again — only a hint of it, later, to help you identify the key.

Note: This is your only chance to see the client secret

Miss it, and there’s no way to reveal it again and will require you revoke the key and create a new one.

What you get

Each key is a pair of credentials, plus the metadata you set when creating it:

Name	Engagement dashboard — production
Client ID	bu_client_8f2a1c9d
Client secret	shown once, at creation only
Status	Active
Created	Aug 27, 2026
Expires	Nov 25, 2026
Permissions	reporting: read

The client ID is safe to share with Support or in logs. The client secret is the real credential — treat it like a password. Status shows as Active, Expired, or Revoked.

Permissions and access levels

Keys are granted specific permissions rather than one all-or-nothing switch (for example, read-only reporting, or read/write accounts). Write always includes the matching read.

The current permissions catalog lives at api.betterup.co/docs and changes over time, so we don’t duplicate it here.

Two rules: you can only grant a permission your own Partner Hub role already has, and you should only grant what the integration actually needs — an engagement dashboard needs read-only reporting, nothing more.

Keep your key safe

A client secret is a password for a system account and should be treated like any other protected password.

Some good rules to follow are:

Store it in a secrets manager, never in code, a spreadsheet, or chat.
Never send it by email or Slack. Support will only ever ask for the client ID.
Ensure one key per integration.
Set an expiration and rotate on a schedule.
Revoke immediately if a secret is ever exposed.

Calling the API

Your developers exchange the client ID and secret for a short-lived access token, then send it as a bearer token on every call:

curl -X POST https://api.betterup.co/oauth/token \

-d grant_type=client_credentials \

-d client_id=YOUR_CLIENT_ID \

-d client_secret=YOUR_CLIENT_SECRET \

-d scope="api:partner:reporting:read"

Authorization: Bearer <access_token>

Full reference and a try-it console: api.betterup.co/docs. SCIM (identity-provider user provisioning) is separate, with its own endpoints — check the docs for availability.

Rotate or revoke a key

To rotate on schedule: create the new key, switch your integration over, confirm it works, then revoke the old one. To respond to a leak: revoke first, replace after.

Open the credentials list: Settings → System and Security → API Credentials.
Find the key: By name or client ID.
Select Revoke and confirm: Immediate and permanent - every token from that key stops working right away.

Revoking breaks anything still using the key

Confirm nothing depends on it first.

Frequently asked questions

Q: Who can create or revoke API keys for our organization?

Anyone with the Manage API Keys permission. View API Keys is read-only.

Q: I closed the dialog without copying the client secret. Can you show it to me again?

No - revoke the key and create a new one.

Q: Can we have more than one API key?

Yes - one per integration is best practice.

Q: Do keys expire automatically?

Only if you set an expiration date. Otherwise a key stays active until someone revokes it.

Q: What happens the moment I revoke a key?

Every token from that key stops working immediately, with no grace period.

Q: I don’t see “API Credentials” anywhere in Settings.

Not enabled yet - contact your Customer Success Manager or Support.

Q: Is this the same system as SCIM user provisioning?

No - SCIM is a separate standard for syncing users from an identity provider like Okta or Azure AD.

Q: Are there rate limits or usage guidelines we should design around?

They vary by endpoint and plan - ask your BetterUp representative before building high-volume integrations.

Q: Who do we contact if something looks wrong — an unfamiliar key, unexpected access, a possible leak?

Revoke the key first, then contact BetterUp Support to investigate.

Updated: August 2026