Admission et activation

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).

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).

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.