Admission and activation

Becoming a member is not a payment: it is an act of the association. Under the Italian Third Sector Code (art. 23) it is the governing body that accepts a request, unless the bylaws say otherwise. Every association on Vimine declares how it admits its members, and your integration reads it before it even shows the form.

What to expect, before asking

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

admission.model	What happens to a request
board	it stays pending until the board (or whoever it delegates) accepts it; the fee is paid after admission
provisional	the member is admitted at once, provisionally; the board ratifies later
automatic	the membership is active as soon as the conditions are met: at once if free, when the fee is paid otherwise

delay_hours is the hours between admission and a usable card (0 = at once). It is a precaution many associations with a venue open to the public adopt: the membership is active from admission, the card counts at the door only afterwards. Tell people when they join: “your card can be used after 24 hours” saves an argument at the entrance.

approval_required stays for compatibility: it is true when the model is board. Read admission.

The answers to a request

POST /v1/me/membership, POST /v1/enroll/confirm and GET /v1/me/membership say the same thing, with the same fields:

Field	Meaning
status	pending · active · suspended · revoked · rejected
pending_reasons	why it is still pending, in order: approval (the association has to decide), then payment (the fee). Empty when active
payment_open	may the fee be paid now? false until the admission: admission opens payment
valid_from	when the card becomes usable, for an active membership inside the interval; null otherwise
usable (GET /v1/me/membership only)	the card counts at the door right now
card (GET /v1/me/membership only)	the signed token — null until the membership is active

With the board model and a paid type the sequence is:

1. request → pending, ["approval", "payment"], payment_open: false — do not show payment instructions or buttons;
2. the association accepts the request → ["payment"], payment_open: true — now you do; the applicant gets an e-mail too;
3. fee recorded → active, possibly with a valid_from in the future;
4. past valid_from → usable: true, and the card answers valid to whoever verifies it.

Before admission even starts, whoever asks for a membership must be identified — by a fiscal code or by their date, place and country of birth: a profile that is not answers identification_required. From there on admission is the same for everybody, with or without a fiscal code (see Members without a fiscal code).

When the request is not accepted

rejected is an outcome of its own: it is not a revocation (which excludes someone who was a member), it is a request not accepted. The decision is reasoned and sent to the applicant by the association, and within sixty days the applicant may ask that the general meeting decides. For your integration: no card, no payment to offer, and the right message is to refer the person to the association.

An active card that is not usable yet

Inside the interval the card exists — the member sees it, saves it to Wallet — but does not count yet:

• 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" with valid_from; the scan is recorded all the same;
• the token carries the same instant in nbf: an offline scanner reaches the same answer alone (see Embed and verify cards).

For members-only events, eligibility answers membership_not_yet_valid if the event starts before valid_from; for anything that starts later, the member registers as usual.

What changed (version 2026-09-19)

All additive, but visible to whoever compares values:

• status may be rejected; verdict may be not_yet_valid; /v1/verify’s reason may be not_yet_valid too;
• pending_reasons is ordered (approval before payment): the order was not meaningful before;
• new fields admission, payment_open, valid_from, usable; payment_instructions arrives only once the payment is open;
• card is null — and /v1/me/membership/card, card.svg, card/email, wallet/google answer 409 not_active — until the membership is active;
• a new reason for not being eligible for an event: membership_not_yet_valid.