Elastic Path User Management API Guide

Auth method: OAuth 2.0 (client_credentials and implicit grant types); Bearer token passed in Authorization header

Setup steps

1. Create a store in Elastic Path Commerce Manager and obtain the Client ID and Client Secret from the store's API keys section.
2. POST to /oauth/access_token with grant_type=client_credentials plus client_id and client_secret to receive a Bearer token (server-side operations).
3. For buyer-facing flows, use grant_type=implicit with client_id only to receive a limited-scope token.
4. Include the token in all subsequent requests as: Authorization: Bearer .
5. Tokens expire; re-request before expiry (expiry returned in the token response as 'expires_in' seconds).

Required scopes

List Account Members

• Method: GET
• URL: https://useast.api.elasticpath.com/v2/account-members
• Watch out for: Requires client_credentials token. Implicit tokens cannot list all members.

Request example

GET /v2/account-members?page[limit]=25&page[offset]=0
Authorization: Bearer <token>

Response example

{
  "data": [
    {"id":"abc-123","type":"account_member","name":"Jane Doe","email":"jane@example.com"}
  ],
  "meta":{"page":{"limit":25,"offset":0,"current":1,"total":1}}
}

Get Account Member

• Method: GET
• URL: https://useast.api.elasticpath.com/v2/account-members/{memberID}
• Watch out for: Member ID must be a valid UUID; 404 returned if not found.

Request example

GET /v2/account-members/abc-123
Authorization: Bearer <token>

Response example

{
  "data": {
    "id":"abc-123",
    "type":"account_member",
    "name":"Jane Doe",
    "email":"jane@example.com"
  }
}

Create Account Membership (associate member to account)

• Method: POST
• URL: https://useast.api.elasticpath.com/v2/accounts/{accountID}/account-memberships
• Watch out for: Account members are global; memberships link them to specific accounts. Creating a member and creating a membership are separate operations.

Request example

POST /v2/accounts/{accountID}/account-memberships
Authorization: Bearer <token>
Content-Type: application/json
{
  "data":{"type":"account_membership","account_member_id":"abc-123"}
}

Response example

{
  "data": {
    "id":"mem-456",
    "type":"account_membership",
    "account_member_id":"abc-123"
  }
}

Delete Account Membership

• Method: DELETE
• URL: https://useast.api.elasticpath.com/v2/accounts/{accountID}/account-memberships/{membershipID}
• Watch out for: Deletes the membership (association), not the account member record itself.

Request example

DELETE /v2/accounts/{accountID}/account-memberships/mem-456
Authorization: Bearer <token>

Response example

HTTP 204 No Content

List Account Memberships for an Account

• Method: GET
• URL: https://useast.api.elasticpath.com/v2/accounts/{accountID}/account-memberships
• Watch out for: Pagination applies; use page[limit] and page[offset].

Request example

GET /v2/accounts/{accountID}/account-memberships
Authorization: Bearer <token>

Response example

{
  "data": [
    {"id":"mem-456","type":"account_membership","account_member_id":"abc-123"}
  ]
}

Generate Account Management Authentication Token

• Method: POST
• URL: https://useast.api.elasticpath.com/v2/account-members/tokens
• Watch out for: Requires a configured Account Authentication Settings resource with an OIDC provider. The token is scoped to the authenticated account member.

Request example

POST /v2/account-members/tokens
Authorization: Bearer <implicit_token>
Content-Type: application/json
{
  "data":{"type":"account_management_authentication_token","authentication_mechanism":"oidc","oauth_authorization_code":"<code>","oauth_redirect_uri":"https://example.com/callback","oauth_code_verifier":"<verifier>"}
}

Response example

{
  "data": {
    "type":"account_management_authentication_token",
    "token":"<jwt>",
    "expires":"2024-01-01T00:00:00Z"
  }
}

Get Account Authentication Settings

• Method: GET
• URL: https://useast.api.elasticpath.com/v2/settings/account-authentication
• Watch out for: Settings are store-scoped. Changes affect all account member authentication for that store.

Request example

GET /v2/settings/account-authentication
Authorization: Bearer <token>

Response example

{
  "data": {
    "type":"account_authentication_settings",
    "enable_self_signup":true,
    "auto_create_account_for_account_members":true
  }
}

Update Account Authentication Settings

• Method: PUT
• URL: https://useast.api.elasticpath.com/v2/settings/account-authentication
• Watch out for: Uses PUT (full replacement semantics), not PATCH.

Request example

PUT /v2/settings/account-authentication
Authorization: Bearer <token>
Content-Type: application/json
{
  "data":{"type":"account_authentication_settings","enable_self_signup":false}
}

Response example

{
  "data": {
    "type":"account_authentication_settings",
    "enable_self_signup":false
  }
}

• Rate limits: Elastic Path does not publicly document specific numeric rate limits in its developer docs. Rate limiting is enforced at the infrastructure level; limits vary by plan and are communicated via contract.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: No public rate limit figures found in official documentation as of research date. Contact Elastic Path support for contractual limits.
• Pagination method: offset
• Default page size: 25
• Max page size: 100
• Pagination pointer: page[limit] and page[offset]

• Webhooks available: Yes
• Webhook notes: Elastic Path supports webhooks (called 'integrations' or 'events') via its Observable Events system. Webhooks can be configured to fire on resource lifecycle events including account and order changes.
• Alternative event strategy: Elastic Path Composer (iPaaS) can be used for event-driven integrations where native webhooks are insufficient.
• Webhook events: account.created, account.updated, account.deleted, account-membership.created, account-membership.deleted, customer.created, customer.updated, customer.deleted

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• SCIM provisioning is not documented in official Elastic Path developer documentation.
• SSO access is managed via access@elasticpath.com for Commerce Manager (admin portal) users.
• Okta and Entra ID SSO are supported for Commerce Manager login but automated SCIM provisioning is not confirmed.
• Account member provisioning for storefront users must be done via the Account Members REST API.

Three scenarios cover the primary lifecycle operations. First, provisioning a new buyer: obtain a client_credentials token, confirm or create the target account via GET/POST /v2/accounts, then retrieve the member ID via GET /v2/account-members?

filter=eq(email,... ) after the member authenticates via OIDC.

Associate them to the account via POST /v2/accounts/{accountID}/account-memberships. Account member records are created by the OIDC authentication flow, not by a direct admin POST - pre-provisioning without an auth flow is not supported in the standard API.

Second, deprovisioning: list memberships via GET /v2/accounts/{accountID}/account-memberships, then DELETE /v2/accounts/{accountID}/account-memberships/{membershipID}. This removes account-level access but does not delete the global account_member record; the member may retain memberships in other accounts. No explicit token revocation endpoint is documented.

Third, configuring OIDC SSO: create an authentication realm via POST /v2/authentication-realms, attach an OIDC profile via POST /v2/authentication-realms/{realmID}/oidc-profiles, then update Account Authentication Settings via PUT /v2/settings/account-authentication. PUT semantics apply - this is full replacement, not PATCH; omitting fields resets them to defaults. Multi-store setups require separate OIDC profile configurations per store.

Provision a new buyer account member and associate with an account

1. Obtain a client_credentials Bearer token via POST /oauth/access_token.
2. Check if the account exists via GET /v2/accounts; create it via POST /v2/accounts if not.
3. The account member record is created automatically upon first successful OIDC authentication, OR can be pre-created if self-signup is disabled by configuring the OIDC provider and directing the user through the authentication flow.
4. After the member record exists, retrieve their member ID via GET /v2/account-members?filter=eq(email,user@example.com).
5. Associate the member to the account via POST /v2/accounts/{accountID}/account-memberships with the account_member_id.

Watch out for: Account member records are created by the authentication flow (OIDC), not by a direct admin POST. Pre-provisioning without an auth flow is not supported in the standard API.

Deprovision a user (remove from account)

1. Obtain a client_credentials Bearer token.
2. List memberships for the account via GET /v2/accounts/{accountID}/account-memberships to find the membership ID.
3. Delete the membership via DELETE /v2/accounts/{accountID}/account-memberships/{membershipID}.
4. Optionally revoke any active account management authentication tokens by expiry (no explicit token revocation endpoint documented).

Watch out for: Deleting a membership removes the user's access to that account but does not delete the account_member record globally. The member may still have memberships in other accounts.

Configure OIDC SSO for account member authentication (Okta/Entra)

1. In your IdP (Okta or Entra ID), create an OIDC application and note the Client ID, Client Secret, and Discovery URL.
2. POST to /v2/authentication-realms to create an authentication realm for your store.
3. POST to /v2/authentication-realms/{realmID}/oidc-profiles with the IdP Client ID, Client Secret, and discovery_url.
4. Update Account Authentication Settings via PUT /v2/settings/account-authentication to reference the realm and set enable_self_signup as appropriate.
5. Direct storefront users to authenticate via the OIDC flow; on success, an account_member record is created and a token is returned.

Watch out for: Each store has its own authentication realm. Multi-store setups require separate OIDC profile configurations per store. The discovery_url must be publicly accessible.

The most common integration trap is treating account member creation as a direct API operation. Member records are generated by the OIDC authentication flow; attempting to pre-provision members without routing them through the auth flow will fail or produce orphaned records.

A second trap is the member/membership distinction: creating a member and associating them to an account are separate API calls - skipping the membership POST leaves the member with no account-level access despite having a valid record.

For teams building an identity graph that spans Elastic Path alongside other SaaS tools, the buyer/admin split is the highest-risk modeling error. Admin users have no API representation; any automated sync must treat Commerce Manager admin access as out-of-band.

Integrations built on an MCP server with 60+ deep IT/identity integrations should map Elastic Path's account_member object exclusively to buyer personas and handle admin lifecycle through SSO or manual processes.

SCIM is not confirmed as available, so any identity graph node representing Elastic Path admin users cannot be kept in sync programmatically without direct vendor engagement.