store/export-customers releases customer records including names, email addresses and addresses.
It is asked for explicitly rather than by default, and it records that it was asked.
At a glance
| Ability | store/export-customers |
| Toolset | WooCommerce — toolset/woocommerce |
| Group | WooCommerce › Customers |
| Requires | WooCommerce, active on the site |
| Capability | manage_options |
| Safety | Read-only, but it releases personal data — and refuses to run without confirm: true, a recorded reason, and a capability beyond administrator. |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
Each gate catches a different mistake. The flag catches an assistant reaching for customer data when aggregate numbers would have answered the question. The confirmation catches a request that was not meant to go this far. The recorded reason means the release is attributable afterwards. And the extra capability means being an administrator is not, by itself, sufficient.
That last one is the unusual gate and the most important. Administering a WordPress site is a technical role; releasing a list of named people is a decision with legal weight, and the two should not be the same permission.
The reason is recorded with who asked and how many records were released. That record is the thing you need when somebody asks, months later, why a customer list left the site.
Always paginated and hard-capped, so a single call cannot release the entire base. The response reports how many records it disclosed and what it withheld.
Password hashes, session tokens and payment provider customer references are never included, regardless of any flag. Those are credentials rather than personal data.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
include_personal_data | boolean | Yes | Required. Without it this refuses. |
reason | string | Yes | Why the export is needed. Recorded with who asked and how many records were released. |
format | string | No | Structured rows or a CSV payload. |
limit | integer | No | How many records to release. |
offset | integer | No | Where to start, for paging. |
confirm | boolean | Yes — must be true | The irreversibility gate. Without it the call is refused before anything is touched. |
What comes back
| Name | Type | What it is |
|---|---|---|
customers | array | The released records, when the structured format is used. |
csv | string | The CSV payload, when that format is used. |
disclosed_count | integer | How many records were released. |
total_matching | integer | How many exist in total. |
has_more | boolean | Whether there are further pages. |
withheld | array | What was not included, and never will be. |
reason | string | The reason as recorded. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Export our customer list for the accountant, with a note of why.
It resolves to one call:
{
"ability": "store/export-customers",
"parameters": {
"include_personal_data": true,
"reason": "Year-end reconciliation requested by the accountant",
"format": "csv",
"limit": 500,
"confirm": true
}
}Worth knowing
- Needs a capability beyond administrator. This is deliberate.
- The reason is recorded. So is who asked and how many records went out.
- Hard-capped and paginated — one call cannot release everybody.
- Credentials and payment provider references are never included.
- Use
store/list-customersif numbers would do.
Related abilities
- List Customers — the answer that identifies nobody
- Get Customer — one customer, without personal data by default
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category