# Admissão e ativação

> Como uma associação admite os seus associados, quando a taxa é paga, quando a carteirinha vale na entrada — e o que dizer a quem se associa pelo seu site.

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

Tornar-se associado não é um pagamento: é um **ato da associação**. Pelo Código do Terceiro Setor italiano (art.
23), é o órgão de administração que aceita um pedido, salvo disposição diversa do estatuto. Cada associação no Vimine
declara como admite os seus associados, e a sua integração lê isso antes mesmo de mostrar o formulário.

## O que esperar, antes de pedir

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

| `admission.model` | O que acontece com um pedido |
| --- | --- |
| `board` | ele fica **pendente** até a diretoria (ou quem ela delegar) aceitá-lo; a taxa é paga **depois** da admissão |
| `provisional` | o associado é admitido na hora, de forma provisória; a diretoria ratifica depois |
| `automatic` | a carteirinha fica ativa assim que as condições são cumpridas: na hora se for gratuita, quando a taxa é paga nos outros casos |

`delay_hours` são as horas entre a admissão e uma **carteirinha utilizável** (0 = na hora). É uma precaução que muitas
associações com um espaço aberto ao público adotam: a carteirinha fica ativa a partir da admissão, mas só vale na
entrada depois. Diga isso às pessoas quando elas se associam: *"a sua carteirinha poderá ser usada daqui a 24 horas"*
evita uma discussão na entrada.

`approval_required` continua por compatibilidade: é `true` quando o modelo é `board`. Leia `admission`.

## As respostas a um pedido

`POST /v1/me/membership`, `POST /v1/enroll/confirm` e `GET /v1/me/membership` dizem a mesma coisa, com os mesmos
campos:

| Campo | Significado |
| --- | --- |
| `status` | `pending` · `active` · `suspended` · `revoked` · `rejected` |
| `pending_reasons` | por que ainda está pendente, **em ordem**: `approval` (a associação precisa decidir), depois `payment` (a taxa). Vazio quando ativa |
| `payment_open` | a taxa já pode ser paga? `false` até a admissão: **a admissão abre o pagamento** |
| `valid_from` | quando a carteirinha se torna utilizável, para uma carteirinha ativa dentro do intervalo; `null` nos outros casos |
| `usable` *(só `GET /v1/me/membership`)* | a carteirinha vale na entrada neste momento |
| `card` *(só `GET /v1/me/membership`)* | o token assinado — `null` até a carteirinha ficar ativa |

Com o modelo `board` e um tipo pago, a sequência é:

1. pedido → `pending`, `["approval", "payment"]`, `payment_open: false` — **não mostre** instruções nem botões
   de pagamento;
2. a associação aceita o pedido → `["payment"]`, `payment_open: true` — agora sim; quem pediu também recebe um
   e-mail;
3. taxa registrada → `active`, eventualmente com um `valid_from` no futuro;
4. passado o `valid_from` → `usable: true`, e a carteirinha responde `valid` para quem a verifica.

Antes mesmo de a admissão começar, quem pede uma carteirinha precisa estar **identificado** — por um código fiscal ou
pela data, local e país de nascimento: um perfil que não está responde `identification_required`. A partir daí a
admissão é a mesma para todos, com ou sem código fiscal (veja
[Associados sem código fiscal](https://developers.vimine.network/pt/guides/members-without-cf/)).

## Quando o pedido não é aceito

`rejected` é um resultado próprio: não é uma revogação (que exclui alguém que era associado), é um pedido
**não aceito**. A decisão é fundamentada e comunicada a quem pediu pela associação, e em até sessenta dias quem pediu
pode solicitar que a assembleia decida. Para a sua integração: nenhuma carteirinha, nenhum pagamento a oferecer, e a
mensagem certa é encaminhar a pessoa para a associação.

## Uma carteirinha ativa que ainda não é utilizável

Dentro do intervalo a carteirinha **existe** — o associado a vê, a salva na Wallet — mas ainda não vale:

- `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"` com `valid_from`; **a leitura é registrada do mesmo jeito**;
- o token traz o mesmo instante em `nbf`: um leitor off-line chega sozinho à mesma resposta (veja
  [Incorporação e verificação das carteirinhas](https://developers.vimine.network/pt/guides/embed-and-verify/)).

Para os eventos só para associados, a elegibilidade responde `membership_not_yet_valid` se o evento começa antes de
`valid_from`; para tudo o que começa depois, o associado se inscreve normalmente.

## O que mudou (versão 2026-09-19)

Tudo aditivo, mas visível para quem compara valores:

- `status` pode ser **`rejected`**; `verdict` pode ser **`not_yet_valid`**; o `reason` de `/v1/verify` também pode ser
  `not_yet_valid`;
- `pending_reasons` é **ordenado** (`approval` antes de `payment`): antes a ordem não tinha significado;
- novos campos `admission`, `payment_open`, `valid_from`, `usable`; `payment_instructions` só chega quando o pagamento
  está aberto;
- `card` é `null` — e `/v1/me/membership/card`, `card.svg`, `card/email`, `wallet/google` respondem `409 not_active` —
  até a carteirinha ficar ativa;
- um novo motivo para não ser elegível a um evento: `membership_not_yet_valid`.