Suppliers Users

A supplier user is linked to a supplier and accesses the supplier back office. They manage incoming orders (e.g. acceptance, fulfillment).

In a single-supplier setup, this role is typically handled by an internal user.

Key Characteristics

  • They can be created in two ways:
    • By the platform operator
    • By the supplier themselves via their supplier dashboard
  • Multiple permission levels are available, defining their access scope in the supplier back office:
    • Admin
    • User
    • Reader
⚠️

Email uniqueness

An email address can only be used once across the entire platform — regardless of the user type (Customer, Admin, or Supplier).

External identifier

Supplier users carry an external identifier, with the same behaviour as everywhere else on the platform (operator users, customer users, suppliers):

  • Optional at creation — provide your own business identifier and it is kept as is.
  • Generated automatically when none is provided, so every supplier user carries one.
  • Unique across the tenant — a duplicate creation is rejected with an explicit error.
  • Immutable — it cannot be changed after the user has been created.

Existing supplier users have all been assigned a generated external identifier, on every tenant: no user is left without one.

The external identifier is displayed in the header of the supplier user detail page in the Back-Office, next to the email address. It is copyable in one click and shown read-only. Nothing is displayed for a user that carries none.

📘

Note: This is an additive change. The existing supplier user endpoints keep their current reference identifier — the external identifier does not replace it, and no existing integration is impacted. Searching supplier users by external identifier on those endpoints is not available. The tenant-wide listing endpoint described below exposes the external identifier as the main id, in line with the platform conventions.

Use the external identifier to reconcile a supplier user in the Back-Office with the corresponding record in your own systems.

Listing supplier users across the tenant

🚧

Available through the API only for now — the matching Back-Office screen will be delivered in a later version.

Unlike operator users and customer users, supplier users used to be reachable only supplier by supplier. A dedicated administration endpoint now returns the supplier users of the whole tenant, all suppliers included, as a paginated list. It is the counterpart of the operator users list and can be used to search a user by name or email, to build user pickers, or to feed reporting processes without knowing the supplier a user belongs to.

Endpoint

  • GET /v1/supplier-users — operationId: ADM-SUPPLIER-USER-550
  • Access: dj-client: OPERATOR, permission SUPPLIER_USER_READ (the same permission as the other supplier user read endpoints — no change to the role catalogue is needed)
  • Store headers have no effect: supplier users are attached to the tenant, not to a store.
  • The existing supplier user endpoints, including the list per supplier, are unchanged.

Identifiers — every identifier exchanged with this endpoint, for users as well as for suppliers, is an external identifier. A value received in a response can be sent back as is in the matching filter.

Available filters — filters are optional and can be combined. AND applies between filters, OR between the values of a single filter.

FilterDescription
supplierIdsOne or several supplier external identifiers
searchFree-text search on first name, last name and email
statusesOne or several user statuses (ACTIVE, NEW, INACTIVE, WAITING_ACTIVATION, APPROBATION_REFUSED)
idsA batch of supplier user external identifiers

Pagination and sortingpage (0-based) and size (default 20, maximum 100). Invalid sort entries are silently ignored.

Response — each user is returned with its own information (email, first name, last name, civility, locale, status, creation and update dates) and its supplier, identified by external identifier and name. Group memberships are neither filterable nor returned: fetch a single supplier user to get them.

GET /v1/supplier-users?supplierIds=sup-001&statuses=ACTIVE&search=martin&page=0&size=20
dj-client: OPERATOR
dj-api-key: <your-api-key>

Response 200 OK:

{
  "content": [
    {
      "id": "sup-user-001",
      "civility": "MRS",
      "firstName": "Alice",
      "lastName": "Martin",
      "email": "[email protected]",
      "locale": "fr-FR",
      "status": "ACTIVE",
      "supplierId": "sup-001",
      "supplierName": "Supplier One",
      "createdAt": "2026-01-15T10:30:00Z",
      "updatedAt": "2026-01-16T08:00:00Z"
    }
  ],
  "number": 0,
  "size": 20,
  "totalElements": 1,
  "totalPages": 1,
  "numberOfElements": 1,
  "first": true,
  "last": true,
  "empty": false
}

Tip: To resolve a supplier user from your own system, send its external identifier in ids. To list the team of one supplier, send the supplier external identifier in supplierIds — no prior lookup of the supplier is needed, and supplierName gives you a readable label straight away.

⚠️

Warning: A size above 100 is rejected with a 400. A 403 is returned when the caller does not hold the SUPPLIER_USER_READ permission. See Error / Warning codes.


Did this page help you?