List the accounts you provisioned, with lifecycle status

Provisions the managed accounts described in an uploaded file, switches each one on in Live, and leaves them ready to invoice. It is the same act as calling `POST /v1/accounts` once per row and then `POST /v1/companies/{company_id}/activations`, with the bookkeeping done for you. **The file is declarative and the import is re-runnable.** Each pass applies only what is missing: an `external_ref` you already provisioned is reconciled, not duplicated, and so are its series and its customers. That is the recovery path for anything that went wrong — fix the cause and upload the same file again. There is no resume and no partial state to clean up. **Two files, one act.** `accounts_file` describes the accounts, one per row. `customers_file` is optional and holds a list of customers applied to **every** account of the import, new and pre-existing alike. It is what makes both directions cheap: a new managed account is born knowing all the customers, and a new customer reaches all the accounts on the next pass. It is the same CSV that `GET /v1/templates/customer-import` describes, and it is idempotent by tax id. **Live activation is part of the act, and it never charges you by surprise.** Every row is weighed against the same verdict the account state publishes, and **only rows entitled to Live are executed**; the rest come back `BLOCKED` with the reason. The import never opens a checkout: chaining N payments inside a file upload would turn a declarative import into a payment flow with intermediate states nobody can recover from. Settle your billing once and re-upload. **Not atomic.** Each row is processed and reported independently: a row that fails leaves the rows already provisioned in place. Read `statistics.accounts_created` to know how many accounts this call actually created. **Claim tokens are shown once.** Each newly provisioned row carries `account.claim_token` and `account.claim_url` in this response and nowhere else. Persist them before discarding the response; a lost token is re-issued with `POST /v1/accounts/{account_id}/claim-tokens`. **Limits:** 5 MB per file; 100 rows in the accounts file and 1,000 in the customers file. The accounts cap is far below the customers one because an account row is an order of magnitude heavier — a provision, a census lookup, a Live activation, its series and its customers — and the answer is synchronous. A larger population is imported in passes, which costs nothing: the file is declarative. **Idempotency:** `Idempotency-Key` is required. The real guarantee, though, is in the data: rows are idempotent by `external_ref`, so the same file uploaded twice creates nothing twice even under a different key. To see what this would do without writing anything, use `POST /v1/accounts/imports/preview`, a separate operation with no effects at all — the import is never governed by a boolean flag. Requires the `accounts:write` scope and the managed-accounts capability on your account.