General

Store Store Login FAQ

Jaapi supports SCIM 2.0 for automated user lifecycle management. Connected to your identity provider, store accounts are created when employees join, kept in sync while they're here, and deactivated when they leave — no manual user admin.

Quick reference

The values you'll paste into your identity provider (Okta, Microsoft Entra, PingOne, …).

SCIM base URL
https://store.jaapi.store/api/scim/v2
Authentication
Bearer token — generate under API Tokens in your store settings
Content type
application/scim+json or application/json
Unique identifier
userName (the user's email address)
Supported resources
Users — groups, bulk operations and passwords are deliberately not supported

What SCIM manages

SCIM owns identity: who has an account, what they're called, and whether they're active. Everything a user does inside the store stays in Jaapi.

Synced from your IdP

  • Account creation — new employees get a store account automatically
  • Profile updates — name and email changes flow through
  • Deprovisioning — departed employees are deactivated when they're offboarded

Stays in Jaapi

  • Credit balance and order history
  • Shipping and billing addresses
  • User role and store preferences

None of these are readable or writable over SCIM.

Authentication

Every request carries a Bearer token in the Authorization header. Store admins create and revoke tokens in the store settings under API Tokens.

Authorization: Bearer <your-scim-token>

Treat tokens like passwords

A SCIM token has full access to user management on this store. It's shown once at creation — copy it straight into your IdP's credential vault. Tokens are store-specific and can't be reused across stores.

Endpoints at a glance

Everything lives under the base URL. The discovery endpoints (GET /ServiceProviderConfig, GET /ResourceTypes, GET /Schemas) describe the implementation's capabilities; most IdPs call them automatically during setup.

POST /Users Create a user (or reactivate a previously deactivated one) GET /Users/{id} Fetch one user by Jaapi UUID GET /Users?filter=… List and search users, paginated up to 1000 per page PATCH /Users/{id} Partial update (SCIM PatchOp — what Entra and Okta send) PUT /Users/{id} Full replace — omitted attributes are cleared DELETE /Users/{id} Permanently deactivate and transfer remaining credit to an admin

User attributes

How SCIM attributes map onto a Jaapi user. Attributes not listed here are ignored on write.

SCIM attributeMaps toAccess
idJaapi user UUIDRead-only
externalIdYour system's user identifierRead / write
userNameEmail address — unique per storeRead / write
name.formattedFull display nameRead / write
name.givenName / name.familyNameFirst / last nameRead / write
emails[0].valueEmail addressRead / write
activeAccount statusRead / write
meta.created / meta.lastModifiedCreated / last login timestampsRead-only

Searching

Filter on userName, externalId or active, and combine terms with and. Results are paginated with startIndex (1-based) and count (max 1000); the response's totalResults tells you how many pages exist.

GET /Users?filter=userName eq "jane.doe@example.com" and active eq true

Create users

The email domain must match the store's allowed domains. New users start without credit — admins allocate it inside Jaapi — unless we've configured an onboarding credit grant for your store.

POST /Users 
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "jane.doe@example.com",
  "name": {
    "formatted": "Jane Doe",
    "givenName": "Jane",
    "familyName": "Doe"
  },
  "emails": [{ "value": "jane.doe@example.com", "type": "work", "primary": true }],
  "externalId": "employee-12345",
  "active": true
}

Returns 201 Created with the user object and a Location header. If the user was previously deactivated, the account is reactivated and 200 OK is returned instead.

Update users

PATCH applies partial updates in the SCIM PatchOp format (RFC 7644 section 3.5.2) — the format Microsoft Entra, Okta and most IdPs send. PUT replaces every mutable attribute at once.

PATCH /Users/{id} 
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "Replace", "path": "name.formatted", "value": "Jane Smith" },
    { "op": "Replace", "path": "active", "value": false }
  ]
}

Supported operations: Replace, Add and Remove — on active, userName, externalId, name and its sub-attributes, emails, and emails[type eq "work"].value (used by Entra). An operation without a path takes a partial user object as its value.

PUT clears what you omit

A PUT request replaces all mutable fields, so leaving externalId out of the body erases the stored value. Use PATCH when you only mean to change specific fields.

Deactivate & delete

Both flows are soft — order history is always retained — and both return the user's unspent credit to one of your store admins so it isn't lost. The reclaimed amount is recorded on the account.

PATCH Deactivate

Set active to false — the standard IdP offboarding signal. Access ends immediately. Setting active back to true reactivates the account, and we can configure your store to restore the reclaimed credit automatically on reactivation — useful for rehires and leaves of absence.

DELETE Delete

Permanent deactivation, returning 204 No Content. Credit is reclaimed the same way.

Admin users can't be deleted over SCIM — the request returns 403. Deactivation works on any account, admins included.

Error responses

Failures return a SCIM-compliant error object with a machine-readable scimType.

Example error body 
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "status": "400",
  "scimType": "invalidValue",
  "detail": "Invalid user data"
}
StatusMeaning
200 / 201 / 204Success — fetched or updated / created / deleted
400Invalid request data
401Missing or invalid Bearer token
403Operation not allowed — e.g. deleting an admin
404User not found in this store
405HTTP method not allowed
501Not supported: group writes (Jaapi uses a flat role model, so GET /Groups lists nothing and nothing can be created), bulk operations, passwords (authentication runs over SSO) and sorting (results are ordered by creation date)

Getting started

Five steps, about fifteen minutes with IdP admin access at hand.

  1. Create a SCIM token under Settings → API Tokens in your store. It's shown once — copy it straight into your IdP's credential vault.
  2. Point your IdP's SCIM provisioning at the base URL from the quick reference, authenticating with the Bearer token.
  3. Map your IdP's attributes — at minimum userName, name.formatted and active. The default mappings in Okta and Entra work as-is.
  4. Run a test sync against one user and confirm the account appears in your store's user admin.
  5. Enable automatic provisioning and assign the app to your team: the group your new hires land in, or in Rippling an access rule that covers them. Onboarding and offboarding are automatic from then on.

Step-by-step setup guides

Dedicated walkthroughs with the exact screens and field names for your provider.

Okta SAML SSO & SCIM on one app integration Microsoft Entra ID Formerly Azure AD — enterprise app & provisioning Ping Identity SAML SSO for PingOne and PingFederate Rippling Custom app with SCIM provisioning, page by page Workday CSV-based provisioning from your HRIS