# Admission et activation

> Comment une association admet ses membres, quand la cotisation est payée, quand la carte fait foi à l’entrée — et que dire aux personnes qui adhèrent depuis votre site.

URL: https://developers.vimine.network/fr/guides/admission/

Devenir membre n’est pas un paiement : c’est un **acte de l’association**. Selon le Code du tiers secteur italien (art.
23), c’est l’organe d’administration qui accepte une demande, sauf si les statuts en disposent autrement. Chaque
association sur Vimine déclare comment elle admet ses membres, et votre intégration le lit avant même d’afficher le
formulaire.

## À quoi s’attendre, avant de demander

```
GET https://api.vimine.network/v1/aps/{slug}
→ { "aps": { …, "admission": { "model": "board", "delay_hours": 24 }, "approval_required": true } }
```

| `admission.model` | Ce qu’il advient d’une demande |
| --- | --- |
| `board` | elle reste **en attente** jusqu’à ce que le conseil (ou la personne qu’il délègue) l’accepte ; la cotisation est payée **après** l’admission |
| `provisional` | le membre est admis tout de suite, à titre provisoire ; le conseil ratifie plus tard |
| `automatic` | l’adhésion est active dès que les conditions sont remplies : tout de suite si elle est gratuite, au paiement de la cotisation sinon |

`delay_hours` est le nombre d’heures entre l’admission et une **carte utilisable** (0 = tout de suite). C’est une
précaution que beaucoup d’associations dont le local est ouvert au public adoptent : l’adhésion est active dès
l’admission, la carte ne fait foi à l’entrée qu’ensuite. Dites-le aux personnes quand elles adhèrent : *« votre carte
sera utilisable dans 24 heures »* évite une discussion à l’entrée.

`approval_required` reste pour la compatibilité : il vaut `true` quand le modèle est `board`. Lisez `admission`.

## Les réponses à une demande

`POST /v1/me/membership`, `POST /v1/enroll/confirm` et `GET /v1/me/membership` disent la même chose, avec les mêmes
champs :

| Champ | Signification |
| --- | --- |
| `status` | `pending` · `active` · `suspended` · `revoked` · `rejected` |
| `pending_reasons` | pourquoi elle est encore en attente, **dans l’ordre** : `approval` (l’association doit décider), puis `payment` (la cotisation). Vide quand elle est active |
| `payment_open` | la cotisation peut-elle être payée maintenant ? `false` jusqu’à l’admission : **l’admission ouvre le paiement** |
| `valid_from` | quand la carte devient utilisable, pour une adhésion active pendant le délai ; `null` sinon |
| `usable` *(`GET /v1/me/membership` seulement)* | la carte fait foi à l’entrée en ce moment |
| `card` *(`GET /v1/me/membership` seulement)* | le jeton signé — `null` tant que l’adhésion n’est pas active |

Avec le modèle `board` et un type payant, la séquence est :

1. demande → `pending`, `["approval", "payment"]`, `payment_open: false` — **n’affichez pas** d’instructions ni de
   boutons de paiement ;
2. l’association accepte la demande → `["payment"]`, `payment_open: true` — maintenant, oui ; la personne reçoit aussi
   un e-mail ;
3. cotisation enregistrée → `active`, éventuellement avec un `valid_from` dans le futur ;
4. `valid_from` passé → `usable: true`, et la carte répond `valid` à qui la vérifie.

Avant même que l’admission commence, la personne qui demande une adhésion doit être **identifiée** — par un code fiscal
ou par sa date, son lieu et son pays de naissance : un profil qui ne l’est pas répond `identification_required`. À
partir de là, l’admission est la même pour tout le monde, avec ou sans code fiscal (voir
[Membres sans code fiscal](https://developers.vimine.network/fr/guides/members-without-cf/)).

## Quand la demande n’est pas acceptée

`rejected` est une issue à part entière : ce n’est pas une révocation (qui exclut quelqu’un qui était membre), c’est
une demande **non acceptée**. La décision est motivée et communiquée à la personne par l’association, et dans les
soixante jours la personne peut demander que l’assemblée générale se prononce. Pour votre intégration : pas de carte,
pas de paiement à proposer, et le bon message consiste à renvoyer la personne vers l’association.

## Une carte active qui n’est pas encore utilisable

Pendant le délai, la carte **existe** — le membre la voit, l’enregistre dans Wallet — mais ne fait pas encore foi :

- `GET /v1/me/membership` → `status: "active"`, `verdict: "not_yet_valid"`, `usable: false`, `valid_from` ;
- `GET /v1/verify/{token}` → `{ "status": "inactive", "reason": "not_yet_valid", "valid_from": "…" }` ;
- `POST /v1/checkins` → `verdict: "not_yet_valid"` avec `valid_from` ; **le passage est enregistré quand même** ;
- le jeton porte le même instant dans `nbf` : un scanner hors ligne arrive seul à la même réponse (voir
  [Intégration et vérification des cartes](https://developers.vimine.network/fr/guides/embed-and-verify/)).

Pour les événements réservés aux membres, l’éligibilité répond `membership_not_yet_valid` si l’événement commence avant
`valid_from` ; pour tout ce qui commence plus tard, le membre s’inscrit normalement.

## Ce qui a changé (version 2026-09-19)

Tout est additif, mais visible pour qui compare les valeurs :

- `status` peut valoir **`rejected`** ; `verdict` peut valoir **`not_yet_valid`** ; le `reason` de `/v1/verify` peut
  aussi valoir `not_yet_valid` ;
- `pending_reasons` est **ordonné** (`approval` avant `payment`) : l’ordre n’avait pas de sens auparavant ;
- nouveaux champs `admission`, `payment_open`, `valid_from`, `usable` ; `payment_instructions` n’arrive qu’une fois le
  paiement ouvert ;
- `card` vaut `null` — et `/v1/me/membership/card`, `card.svg`, `card/email`, `wallet/google` répondent
  `409 not_active` — tant que l’adhésion n’est pas active ;
- une nouvelle raison de ne pas être éligible à un événement : `membership_not_yet_valid`.