# Admission and activation

> How an association admits its members, when the fee is paid, when the card counts at the door — and what to tell people who join from your site.

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

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](https://developers.vimine.network/en/guides/members-without-cf/)).

## 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](https://developers.vimine.network/en/guides/embed-and-verify/)).

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