WooCommerce 11.0 adds REST support for viewing Analytics import status and retrying failed imports. The useful security test separates read access from a state-changing retry, then checks whether failed order IDs, overflow details, timestamps, job state, and error messages expose more operational data than each role needs.
Use this for stores with custom support roles, shop managers, agency users, dashboard integrations, monitoring jobs, delegated administrators, or plugins that call the Analytics import endpoints.
Quick answer
WooCommerce 11.0 Analytics Import Status Permission Audit should be handled with a narrow evidence-first workflow: build the role matrix, test status reads, test controlled retries, then verify the result before making broader changes.
What to check first
- Create administrator, shop manager, support, editor, subscriber, logged-out, and application-password test identities with no shared browser session.
- Call GET /wc-analytics/imports/status for each identity and record HTTP status, response fields, failed order IDs, overflow details, timestamps, and authentication method.
- Call POST /wc-analytics/imports/retry-failed only against a controlled failed import and capture nonce or credential scope, capability checks, job creation, duplicate retry handling, and audit logs.
- Repeat after changing one role capability and after revoking the application password so cached authorization cannot hide the result.
- Confirm support handoff contains enough evidence to diagnose the failure without exposing unnecessary customer or order data.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build the role matrix | Create administrator, shop manager, support, editor, subscriber, logged-out, and application-password test identities with no shared browser session. | Each role receives the expected HTTP status and no extra response fields. |
| Test status reads | Call GET /wc-analytics/imports/status for each identity and record HTTP status, response fields, failed order IDs, overflow details, timestamps, and authentication method. | Only approved identities can create a retry job, and duplicate clicks do not create uncontrolled parallel work. |
| Test controlled retries | Call POST /wc-analytics/imports/retry-failed only against a controlled failed import and capture nonce or credential scope, capability checks, job creation, duplicate retry handling, and audit logs. | Revoked credentials fail immediately and browser sessions do not reuse stale authorization. |
| Revoke and retest | Repeat after changing one role capability and after revoking the application password so cached authorization cannot hide the result. | Logs identify actor, endpoint, timestamp, controlled job, result, and follow-up without copying customer data. |
Why this usually happens
- A read endpoint and a state-changing retry endpoint can require different capabilities.
- Custom roles may inherit broad WooCommerce capabilities through another plugin.
- REST authentication, browser nonces, and application passwords use different request paths.
- Diagnostic responses can reveal order identifiers or job details even when the user cannot open the order screen.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Use a staging site and a controlled failed import.
curl -sS -u 'audit-admin:APP_PASSWORD' \
https://store.test/wp-json/wc-analytics/imports/status
curl -sS -X POST -u 'audit-admin:APP_PASSWORD' \
https://store.test/wp-json/wc-analytics/imports/retry-failed
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build the role matrix
- Test status reads
- Test controlled retries
- Revoke and retest
- Minimize support evidence
Decision rule
Grant only the capability required for the approved job. A user who can view high-level import health does not automatically need failed order identifiers or permission to start retries. Every state-changing call should have an owner and an auditable result.
What to tell the client or owner
Provide WooCommerce version, route, HTTP method, test role and capabilities, authentication type, status code, sanitized response fields, failed import fixture, retry job ID, logs, expected access, and credential revocation result.
Production verification checklist
- Each role receives the expected HTTP status and no extra response fields.
- Only approved identities can create a retry job, and duplicate clicks do not create uncontrolled parallel work.
- Revoked credentials fail immediately and browser sessions do not reuse stale authorization.
- Logs identify actor, endpoint, timestamp, controlled job, result, and follow-up without copying customer data.
Mistakes to avoid
- Do not test retry permissions against an uncontrolled production backlog.
- Do not assume a hidden admin menu means the REST route is protected.
- Do not give a support role full administrator access only to read import health.
- Do not store application passwords in command history or a ticket.
Questions teams ask during testing
Should a shop manager be able to retry failed imports?
That is a business and access-control decision. Test the core behavior, document the operational owner, and grant the narrowest capability that supports the approved workflow.
Can a monitoring integration call the status endpoint?
Yes only if the store approves it and the credential scope, response fields, storage, rotation, and revocation are documented. A health check should not collect order-level data it does not need.
When HandL WP should help
HandL WP should help when Analytics imports fail but support users cannot diagnose them, or when a custom role can trigger retries it should not control. We can test the route, capability map, response exposure, and operational handoff.
If this is active on a production site, audit WooCommerce Analytics permissions.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Audit the consolidated activity-panel counts request
Use the WooCommerce 11.1 activity panel counts API audit to compare the six legacy requests with the new aggregate route, count parity, permissions, invalidation, latency, and extension clients.
Helpful references