Customers — Overview
Current source defines Customers as an authenticated level-3 user inventory with private search, filter, detail, export, state-change, creation, and deletion surfaces. This guide documents source behavior only; no customer record or production data was accessed.
The list requests customer names, contact data, addresses, location-related fields, verification state, wallets, order counts, push tokens, and other configured relationships. GET and HEAD are not presumed safe. Do not mount this page with production data for documentation or capture returned values.
Availability and automatic reads
The /users/customers route and Users sidebar parent require level-0 administrator access; the parent also excludes read-only state. Route visibility is separate from API authorization. On mount, the shared user controller requests active level-3 records and repeats the request when search, filters, active state, pagination, or order-count controls change.
Source-defined search and filters
The main search alone is wired to the cellphone field. Quick controls can request all results or order-count comparisons for no orders, at least one order, or at least five orders. The rendered Customer filter dialog contains customer ID, external ID, name, email, last name, order-count condition/value, phone verification, email verification, sign-up date, and loyalty level. Generic controller query keys that are not rendered in this dialog are not documented as Customer controls.
These controls construct authenticated queries containing private values. A list label, verification badge, order count, or New indicator reflects returned data only and is not independent verification of the person's identity or order history.
Use advanced filters
Select the filter icon beside the search field to open the Filter dialog.
Applying or clearing this dialog causes another authenticated list request. No search term, filter value, result row, or count was submitted or inspected.
Export is a job and outbound data boundary
The CSV control requests the versioned user-export endpoint with active level and advanced filters. Current API source requires an email on the requesting account, enforces an in-progress/penalty boundary, and dispatches a user-file generation job. A success response does not prove that a file was generated, delivered, retained safely, or limited to the intended rows.
Exports can disclose customer PII and create asynchronous or outbound effects. No export, file, job, message, or destination is authorized by this documentation goal.
Persistent actions and partial-failure risk
The page also includes administrative controls that are intentionally outside the normal lookup workflow:
- Add user can create a customer account.
- The row and detail Enable switches submit the account-state change immediately.
- Opening a direct-ID detail can issue another PII read; its tabs can read additional profile, wallet, metadata, address, or order data.
- Single delete changes identifiers, deletes the record, writes an audit log, and can invoke plugin actions.
- Bulk delete can mutate eligible selected records while leaving protected records untouched.
In the inspected API source, eligible unprotected records are mutated and deleted before the response reports that protected users in the same selection could not be deleted. Do not interpret an error as proof that nothing changed, and do not retry without an immutable affected-record receipt.
What remains unverified
Without immutable serving receipts and a fully synthetic PII-free customer fixture with exports, messaging, session effects, uploads, wallets, metadata, and all writes intercepted, this page does not claim deployed access, filter correctness, record completeness, export completion, deletion atomicity, successful state change, or safe retry.