Admisión y activación

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

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

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.