Glassdoor User Management API Guide

Auth method: Not documented

User object field mapping is not yet verified for this app.

Endpoint coverage is not yet verified for this app.

• Rate limits: Not documented

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: Not documented

• Pagination method: none

• Default page size: 0

• Max page size: 0

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: No webhook infrastructure for user-management events is documented by Glassdoor.

• Alternative event strategy: User provisioning and deprovisioning must be performed manually via the Glassdoor Employer Center UI, or indirectly controlled through SSO (SAML 2.0) identity provider session policies.

• SCIM available: No
• SCIM version: Not documented
• Plan required: N/A
• Endpoint: Not documented

Limitations:

• Glassdoor does not document SCIM 2.0 support in any official help or developer documentation.
• No SCIM endpoint has been publicly disclosed.
• User lifecycle management is not automatable via a published API.

Three operational scenarios are relevant for engineers managing Glassdoor access. First, offboarding: there is no API call available - removal must be performed manually via Employer Center → Account Settings → User Management. Revoking an IdP session via SSO prevents future logins but leaves the Glassdoor account record intact.

Second, SSO enforcement via Okta requires contacting Glassdoor enterprise support to obtain SAML metadata, then configuring a SAML 2.0 app in Okta with the provided ACS URL and Entity ID. Critically, SSO enforcement does not auto-provision new user records; initial seat creation remains a manual step.

Third, the legacy Partner API (GET https://api.glassdoor.com/api/api.htm) is accessible only to existing partners with a partner key and user agent string. It returns employer and review data only - not account or seat data - and new partner access is not being granted.

Offboard an employee from Glassdoor employer account

1. Log in to Glassdoor Employer Center (employer.glassdoor.com).
2. Navigate to Account Settings > User Management.
3. Locate the user and select 'Remove User'.
4. Confirm removal - no API call available.

Watch out for: There is no API or SCIM endpoint to automate this. If SSO is configured, revoking the user's IdP session prevents future logins but does not remove the Glassdoor account record.

Enforce SSO for all employer users (Okta)

1. Contact Glassdoor enterprise support to enable SSO on the account.
2. Obtain the Glassdoor SAML metadata/ACS URL from your account representative.
3. Configure a SAML 2.0 application in Okta with the provided ACS URL and Entity ID.
4. Assign the Okta app to relevant users/groups.
5. Test SSO login via the Glassdoor Employer Center.

Watch out for: SSO enforcement does not provision new Glassdoor user records automatically; initial user seats must still be created manually or by Glassdoor support.

Retrieve company review data via legacy partner API

1. Note: The Glassdoor Partner API is closed to new applicants as of recent years.
2. Existing partners authenticate with a partner key + user agent string (HTTP Basic-style header).
3. GET https://api.glassdoor.com/api/api.htm?v=1&format=json&t.p=&t.k=&action=employers
4. Parse JSON response for employer/review data.

Watch out for: This API covers public review/job data only - not user accounts or seat management. New partner access is not being granted.

The primary automation trap is assuming that SSO coverage equals lifecycle coverage. Configuring Glassdoor as a SAML app in your IdP closes the authentication gap but leaves provisioning and deprovisioning entirely manual.

An offboarded employee whose IdP account is disabled can no longer log in via SSO, but their Glassdoor Employer Center record persists and could be reactivated if SSO is ever bypassed or misconfigured.

With no SCIM endpoint, no webhooks, and no user-management API, there is no reliable programmatic path to keep an identity graph current for Glassdoor. Any automation layer - including an MCP server with 60+ deep IT/identity integrations - would need to treat Glassdoor as a manual-exception node rather than an auto-reconciled integration.

Engineers should document this gap explicitly in access review runbooks and not rely on IdP sync as a substitute for confirmed removal.