Admissão e ativação

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

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

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.