OpenCart User Management

OpenCart separates admin users (back-office staff) from customers (storefront shoppers) with completely independent authentication systems. Admin permissions are managed through User Groups that control access to specific admin routes using an Access/Modify permission matrix. There are no per-store or per-product scoping options in core -- permissions are either granted or denied for an entire admin controller.

Permission model

OpenCart's admin permission system is route-based:

• User Groups -- each group contains two permission arrays: access (can view the page) and modify (can create, edit, delete). Permissions map directly to admin controller routes like catalog/product, sale/order, extension/analytics.
• Users -- admin accounts assigned to exactly one User Group. The user inherits all access/modify routes from their group.
• Route matching -- when an admin loads a page, OpenCart checks if the user's group has access permission for that route. Save/delete actions check modify. No match = "Permission Denied" error.

There is no role hierarchy or inheritance. Each User Group is a flat set of allowed routes.

Built-in user groups

Additional groups are created at System > Users > User Groups. When creating a new group, you manually check each route for access and modify rights.

Common custom groups:

Admin UI paths

API access management

OpenCart has two API systems:

Admin API (built-in):

• Configured at System > Users > API
• Each API user has a key and optional IP whitelist
• Used internally for admin AJAX calls and can be called externally
• Permissions follow the calling session's User Group -- API calls are authenticated via session token
• Add allowed IPs to restrict where API calls originate

REST/JSON API (OpenCart 4.x / extensions):

• OpenCart 4 introduced a more standard REST API
• Authentication via API key in request header
• Third-party extensions (e.g., opencart-rest-api) provide OAuth2 flows
• Scope is typically all-or-nothing per API key unless the extension supports granular scopes

API key management:

• Keys are stored in the oc_api table
• No built-in expiration; rotate manually at System > Users > API
• IP whitelist is the primary security control for API access

Analytics-specific permissions

OpenCart groups analytics under the extension/analytics route namespace:

• Extension routes -- each analytics extension (Google Analytics, Facebook Pixel, etc.) registers as extension/analytics/<extension_name>. Grant access to view configuration and modify to change tracking settings.
• Built-in reports -- sales, products, customers, and marketing reports live under report/* routes. A marketing user needs access to report/sale, report/customer, and report/marketing routes.
• Google Analytics extension -- ships with OpenCart at extension/analytics/google. Configuration includes Measurement ID and tracking options. Only users with modify on this route can change the tracking code.
• Dashboard widgets -- the admin dashboard (common/dashboard) shows sales charts and recent activity. Any user with access to common/dashboard sees these widgets.

To create an analytics-only user: create a "Reports" User Group with access permission on report/* routes and extension/analytics/*. Grant modify only on specific analytics extensions they need to configure. Deny all catalog/*, sale/*, and system/* routes.

Sub-pages

• Roles and Permissions -- User Group configuration, route permission matrix, and multi-store considerations
• Adding and Removing Users -- creating admin accounts, assigning groups, managing API users, and disabling access