# Admisión y activación

> Cómo admite una asociación a sus socios, cuándo se paga la cuota, cuándo vale el carné en la entrada — y qué decir a quien se inscribe desde tu sitio.

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

Hacerse socio no es un pago: es un **acto de la asociación**. Según el Código del Tercer Sector italiano (art. 23),
es el órgano de administración el que acepta una solicitud, salvo que el estatuto diga otra cosa. Cada asociación en
Vimine declara cómo admite a sus socios, y tu integración lo lee incluso antes de mostrar el formulario.

## Qué esperar, antes de solicitar

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

| `admission.model` | Qué le ocurre a una solicitud |
| --- | --- |
| `board` | queda **pendiente** hasta que la junta directiva (o quien esta delegue) la acepta; la cuota se paga **después** de la admisión |
| `provisional` | el socio queda admitido enseguida, de forma provisional; la junta directiva lo ratifica más tarde |
| `automatic` | la inscripción está activa en cuanto se cumplen las condiciones: enseguida si es gratuita, al pagar la cuota en caso contrario |

`delay_hours` son las horas entre la admisión y un **carné que se puede usar** (0 = de inmediato). Es una precaución
que adoptan muchas asociaciones con un local abierto al público: la inscripción está activa desde la admisión, el
carné vale en la entrada solo después. Díselo a las personas cuando se inscriben: *«tu carné se podrá usar dentro de
24 horas»* ahorra una discusión en la entrada.

`approval_required` se mantiene por compatibilidad: es `true` cuando el modelo es `board`. Lee `admission`.

## Las respuestas a una solicitud

`POST /v1/me/membership`, `POST /v1/enroll/confirm` y `GET /v1/me/membership` dicen lo mismo, con los mismos campos:

| Campo | Significado |
| --- | --- |
| `status` | `pending` · `active` · `suspended` · `revoked` · `rejected` |
| `pending_reasons` | por qué sigue pendiente, **en orden**: `approval` (la asociación tiene que decidir), luego `payment` (la cuota). Vacío cuando está activa |
| `payment_open` | ¿se puede pagar ya la cuota? `false` hasta la admisión: **la admisión abre el pago** |
| `valid_from` | cuándo se podrá usar el carné, para una inscripción activa dentro del intervalo; `null` en los demás casos |
| `usable` *(solo `GET /v1/me/membership`)* | el carné vale en la entrada ahora mismo |
| `card` *(solo `GET /v1/me/membership`)* | el token firmado — `null` hasta que la inscripción esté activa |

Con el modelo `board` y un tipo de pago, la secuencia es:

1. solicitud → `pending`, `["approval", "payment"]`, `payment_open: false` — **no muestres** instrucciones ni botones
   de pago;
2. la asociación acepta la solicitud → `["payment"]`, `payment_open: true` — ahora sí; el solicitante también recibe
   un correo;
3. cuota registrada → `active`, posiblemente con un `valid_from` en el futuro;
4. pasado `valid_from` → `usable: true`, y el carné responde `valid` a quien lo verifique.

Antes incluso de que empiece la admisión, quien solicita un carné debe estar **identificado** — con un código fiscal
o con su fecha, lugar y país de nacimiento: un perfil que no lo está responde `identification_required`. A partir de
ahí, la admisión es la misma para todos, con o sin código fiscal (consulta
[Socios sin código fiscal](https://developers.vimine.network/es/guides/members-without-cf/)).

## Cuando la solicitud no se acepta

`rejected` es un resultado en sí mismo: no es una revocación (que excluye a alguien que era socio), es una solicitud
**no aceptada**. La decisión se motiva y la asociación la comunica al solicitante, que en un plazo de sesenta días
puede pedir que decida la asamblea. Para tu integración: ningún carné, ningún pago que ofrecer, y el mensaje adecuado
es remitir a la persona a la asociación.

## Un carné activo que todavía no se puede usar

Dentro del intervalo, el carné **existe** — el socio lo ve, lo guarda en Wallet — pero todavía no 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"` con `valid_from`; **la lectura se registra igualmente**;
- el token lleva el mismo instante en `nbf`: un escáner sin conexión llega solo a la misma respuesta (consulta
  [Integración y verificación de carnés](https://developers.vimine.network/es/guides/embed-and-verify/)).

Para los eventos solo para socios, la elegibilidad responde `membership_not_yet_valid` si el evento empieza antes de
`valid_from`; para todo lo que empiece después, el socio se inscribe como siempre.

## Qué ha cambiado (versión 2026-09-19)

Todo es aditivo, pero visible para quien compara valores:

- `status` puede ser **`rejected`**; `verdict` puede ser **`not_yet_valid`**; el `reason` de `/v1/verify` también
  puede ser `not_yet_valid`;
- `pending_reasons` está **ordenado** (`approval` antes de `payment`): antes el orden no tenía significado;
- nuevos campos `admission`, `payment_open`, `valid_from`, `usable`; `payment_instructions` solo llega cuando el pago
  está abierto;
- `card` es `null` — y `/v1/me/membership/card`, `card.svg`, `card/email`, `wallet/google` responden
  `409 not_active` — hasta que la inscripción esté activa;
- un motivo nuevo para no ser elegible para un evento: `membership_not_yet_valid`.