Sandbox and test clients

Every association can have a sandbox: a twin association with the same branding, the same membership types and the same statuto, populated with synthetic members. You develop and test there without touching real data, and without needing any approval.

Every developer the platform invites also has one of their own, belonging to no association: they create, open, rebuild and delete it from Account settings › Developer, and register their test clients inside it.

Creating it

From the Developers console: the Create sandbox button, or register a client in the Test environment — the sandbox is created on demand. Whoever creates it becomes its director: from the association switcher they can enter it and use the back office on the synthetic data (approve a request, suspend a card, …).

The synthetic members

Six accounts, one per state, with e-mail <state>@<slug>-sandbox.sandbox.invalid and one shared password, shown once at creation and at every reset:

E-mail	State	What it stands for
attivo@…	active	valid card, statuto accepted — verdict: valid
in-attesa@…	pending	request not yet approved
sospeso@…	suspended
revocato@…	revoked
scaduto@…	active but expired	verdict: expired
statuto-da-accettare@…	active, statuto not accepted	verdict: statuto_required

They sign in from the normal Vimine login page, so you can try Sign in with Vimine end to end: click on your site → sign in as attivo@… → consent → callback → API.

Tip

To try the membership request (membership:request) by someone who is not a member yet, sign in with an account that has no card in that sandbox, for instance a personal account of yours: consent to the enrolment permissions is allowed to non-members too.

The people your tests make

Whoever enrols through the sandbox’s enrolment page, and whoever a test client names with /v1/signup or /v1/enroll, becomes a synthetic person of the sandbox: the address typed is replaced by one on its domain (api-…@<slug>-sandbox.sandbox.invalid, always the same for the same address), which the page shows at the end of the enrolment. No real account is created or touched, and no e-mail is sent.

These accounts are valid in the sandbox only: they sign in there with the password chosen, but cannot join a real association, enter another one, or authorize any client other than their sandbox’s test clients (sandbox_account).

Test clients

A client in the Test environment (vms_test_… for confidential ones) is bound to the sandbox, shows up in the real association’s console, is active immediately and issues tokens with mode: "test". It cannot touch the real association. Sandbox e-mails are not sent.

To go to production register a second client in the Production environment (with the same https redirect URIs) and, once it is activated, change clientId in your configuration: the code stays the same.

Reset

Regenerate data and credentials from the console, or with a test client:

Node

import { VimineServer } from '@vimine/sdk/server';

const vimineServer = new VimineServer({ clientId: 'vmc_…', clientSecret: 'vms_test_…' });
await vimineServer.sandbox.members();                      // GET  /v1/sandbox
const { password } = await vimineServer.sandbox.reset();   // POST /v1/sandbox/reset — members start over, new password

The reset recreates the six synthetic members (consents and sessions included) and changes their password; the people your tests made are deleted; the clients and the sandbox stay. These endpoints want the token of a confidential test client (client_credentials), not HTTP Basic; a production client gets 403.

Deleting it

Delete sandbox in the Developers console (the board, or the platform operator) deletes it at once, with its synthetic members, the people your tests made, the data and the test clients, which stop working. You can create a new one whenever you like.