> For the complete documentation index, see [llms.txt](https://features.scnd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://features.scnd.com/v2.0/superadmin/users/importing-claimable-users.md).
# Importing claimable users
Creating claimable vendor accounts in bulk from a CSV file
{% hint style="info" %}
*Path: Backoffice > Users > Users > Import claimable vendor accounts*
{% endhint %}
* [Definition](#id-1.16.x-viewingandmanagingusers-definition)
* [Accessing the import](#accessing-the-import)
* [Step 1 — Upload CSV file](#step-1-upload-csv-file)
* [Step 2 — Preview](#step-2-preview)
* [Processing](#processing)
* [Step 3 — Result](#step-3-result)
* [Finding imported accounts](#finding-imported-accounts)
* [Special rules](#special-rules)
* [Related resources](#related-resources)
## Definition
This interface lets operators create vendor accounts in bulk from a CSV file, instead of creating them one by one. The accounts created this way are *claimable*: the vendors they belong to can later take ownership of them through the front office. See [Account claiming](/v2.0/core-concepts/account-claiming.md) for the overall principle.
The import is only available when account claiming is enabled in the platform configuration.
Imported accounts have no password and cannot be logged into until they are claimed. The vendor chooses his sign-in address during the claiming process.
The import creates accounts only. Listings belonging to those vendors are not part of this interface and must be created separately.
## Accessing the import
From the users list view, click the "Import claimable vendor accounts" button at the top right of the interface (figure 1).
Figure 1
The import runs in three steps — upload the file, review the analysis, confirm the creation — with a processing screen while the accounts are being created.
### Step 1 — Upload CSV file
Select the file to import, then click "Validate and preview" (figure 2). The file must be a comma-separated CSV encoded in UTF-8.
Figure 2
Two downloads are available on this screen:
* **Download CSV template** — an empty file containing the expected header row.
* **Download the category list** — the user categories of the platform with their ids, to be used in the `user_categories` column.
The expected format is documented directly on the screen (figure 3):
| Column | Required? | Format | Example |
| ---------------------- | --------- | ---------------------------------------------------------------------------- | -------------------------------------------------- |
| first\_name | Required | Free text | Xavier |
| last\_name | Required | Free text | Piccino |
| company\_name | Required | Free text | IDVERDE |
| birthday | Optional | YYYY-MM or YYYY-MM-DD | 1984-01 |
| siret | Required | Exactly 14 digits | 33960966101806 |
| legal\_person\_type | Optional | Platform value (BUSINESS…) or INSEE nature\_juridique code | BUSINESS or 5710 |
| country\_of\_residence | Optional | 2-letter ISO code | FR |
| address | Optional | Full postal address on a single line (street, postal code, city) | 25 QUAI DU PRESIDENT PAUL DOUMER, 92400 COURBEVOIE |
| is\_claimable | Optional | true or false (default: true) | true |
| claim\_contact\_email | Optional | Valid email address, the one the vendor is invited to claim their account at | |
| phone\_prefix | Optional | Phone country code | +33 |
| phone | Optional | Number without country code | 644621315 |
| user\_categories | Optional | User category ids, separated by \| | 12\|15 |
Figure 3
A file may contain up to 1000 rows and weigh up to 5 Mo.
Note the following behaviours:
* There is no login email column. `claim_contact_email` is the address the claim invitation is sent to, not a login. A row without it creates an account whose claim status is *Pending (no email)*: the account is claimable, but no invitation can be sent until an operator provides a contact email from the user detailed view (see [Account claiming management](/v2.0/superadmin/users/account-claiming-management.md)).
* The SIRET identifies the company on the platform and must be unique. A SIRET already used by an existing account rejects the row.
* `is_claimable` set to false creates a regular operator-created vendor account, with the "Claimable account" option left unticked in the user detailed view. The row is imported all the same.
* Every address provided is resolved through Google Maps during the analysis. An address that cannot be found or that is inconsistent rejects the row; a row without an address is imported without one.
* The user categories of the platform are listed at the bottom of the screen with their ids (figure 4). Copy the ids into the `user_categories` column, separated by |.
Figure 4
If the file itself cannot be read — wrong extension, unreadable encoding, missing mandatory column — the whole file is rejected and no row is analysed.
### Step 2 — Preview
Every row of the file is analysed individually and the result is displayed before anything is created (figure 5). A counter at the top of the screen summarises the analysis: number of valid rows, number of rows in error, total number of rows.
Figure 5
The table displays the content of each row as read from the file, plus three columns produced by the analysis:
* **Status** — whether the row is valid or in error.
* **Resolved address (Google)** — the address as resolved by Google Maps, with its coordinates, to be compared with the address declared in the file.
* **Error** — the reason why the row was rejected, when applicable.
Typical rejection reasons include:
* SIRET already in use
* Email already linked to an account
* Invalid is\_claimable value (expected true or false)
Two actions are available: "Import X valid rows" launches the creation, "Cancel and re-upload" goes back to step 1.
Rows in error are never imported. Valid rows can be imported even if other rows are in error. When no row is valid at all, the import cannot proceed: a warning message invites the operator to correct the file and upload it again.
### Processing
Account creation runs in the background. Once the import is launched, a processing screen displays the name of the imported file, the current state of the job and a progress bar (figure 6).
Figure 6
The operator does not have to stay on this screen for the import to complete.
### Step 3 — Result
When the job is over, the result screen displays the number of accounts created and the number of rows that were not imported (figure 7).
Figure 7
Two actions are available: "Back to user list" returns to the users list view, "New import" starts a fresh import at step 1.
## Finding imported accounts
Two filtering options of the users list view relate to claimable accounts (figure 8):
* **Show imported users** — restricts the list to the accounts created through an import.
* **Claim status** — restricts the list to a given claim status.
Figure 8
## Special rules
* An import that makes no progress for longer than the "Stalled import timeout" delay is considered interrupted and marked as failed.
* Finished imports are kept for the duration of the "Claimable vendor import retention" delay, then deleted. This is processing state, not a browsable history of past imports.
* Accounts are created with the Vendor role and are claimable by default.
* No email is sent to the vendor when his account is created. Invitations are sent separately, either manually or automatically.
## Related resources
* [Account claiming](/v2.0/core-concepts/account-claiming.md)
* [Account claiming management](/v2.0/superadmin/users/account-claiming-management.md)
* [Claim a user account](/v2.0/front-office/claim-a-user-account.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://features.scnd.com/v2.0/superadmin/users/importing-claimable-users.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
