Aufnahme und Aktivierung

Mitglied zu werden ist keine Zahlung: Es ist ein Akt des Vereins. Nach dem italienischen Kodex des Dritten Sektors (Art. 23) nimmt das Leitungsorgan einen Antrag an, sofern die Satzung nichts anderes bestimmt. Jeder Verein auf Vimine erklärt, wie er seine Mitglieder aufnimmt, und Ihre Integration liest das, noch bevor sie das Formular zeigt.

Was zu erwarten ist, bevor Sie fragen

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

admission.model	Was mit einem Antrag geschieht
board	er bleibt ausstehend, bis der Vorstand (oder wen er beauftragt) ihn annimmt; der Mitgliedsbeitrag wird nach der Aufnahme gezahlt
provisional	das Mitglied wird sofort vorläufig aufgenommen; der Vorstand bestätigt später
automatic	die Mitgliedschaft ist aktiv, sobald die Bedingungen erfüllt sind: sofort, wenn sie kostenlos ist, sonst wenn der Beitrag gezahlt ist

delay_hours sind die Stunden zwischen der Aufnahme und einem nutzbaren Ausweis (0 = sofort). Es ist eine Vorsicht, die viele Vereine mit einem öffentlich zugänglichen Lokal walten lassen: Die Mitgliedschaft ist ab der Aufnahme aktiv, der Ausweis gilt am Einlass erst danach. Sagen Sie es den Menschen beim Beitritt: „Ihr Ausweis ist nach 24 Stunden nutzbar“ erspart eine Diskussion am Eingang.

approval_required bleibt aus Kompatibilitätsgründen: Es ist true, wenn das Modell board ist. Lesen Sie admission.

Die Antworten auf einen Antrag

POST /v1/me/membership, POST /v1/enroll/confirm und GET /v1/me/membership sagen dasselbe, mit denselben Feldern:

Feld	Bedeutung
status	pending · active · suspended · revoked · rejected
pending_reasons	warum er noch aussteht, in Reihenfolge: approval (der Verein muss entscheiden), dann payment (der Mitgliedsbeitrag). Leer, wenn aktiv
payment_open	darf der Beitrag jetzt gezahlt werden? false bis zur Aufnahme: Die Aufnahme öffnet die Zahlung
valid_from	wann der Ausweis nutzbar wird, bei einer aktiven Mitgliedschaft innerhalb der Frist; sonst null
usable (nur GET /v1/me/membership)	der Ausweis gilt gerade jetzt am Einlass
card (nur GET /v1/me/membership)	das signierte Token — null, bis die Mitgliedschaft aktiv ist

Mit dem Modell board und einer kostenpflichtigen Art ist die Abfolge:

1. Antrag → pending, ["approval", "payment"], payment_open: false — zeigen Sie keine Zahlungsanweisungen oder Schaltflächen;
2. der Verein nimmt den Antrag an → ["payment"], payment_open: true — jetzt ja; die antragstellende Person erhält auch eine E-Mail;
3. Beitrag erfasst → active, eventuell mit einem valid_from in der Zukunft;
4. nach valid_from → usable: true, und der Ausweis antwortet valid bei jeder Prüfung.

Noch bevor die Aufnahme beginnt, muss jede Person, die eine Mitgliedschaft beantragt, identifiziert sein — über eine Steuernummer oder über Geburtsdatum, Geburtsort und Geburtsland: Ein Profil, das es nicht ist, antwortet identification_required. Von da an ist die Aufnahme für alle gleich, mit oder ohne Steuernummer (siehe Mitglieder ohne Steuernummer).

Wenn der Antrag nicht angenommen wird

rejected ist ein eigenes Ergebnis: Es ist kein Widerruf (der jemanden ausschließt, der Mitglied war), sondern ein nicht angenommener Antrag. Die Entscheidung wird begründet und vom Verein an die antragstellende Person geschickt, und innerhalb von sechzig Tagen kann diese verlangen, dass die Mitgliederversammlung entscheidet. Für Ihre Integration: kein Ausweis, keine Zahlung anzubieten, und die richtige Nachricht verweist die Person an den Verein.

Ein aktiver Ausweis, der noch nicht nutzbar ist

Innerhalb der Frist existiert der Ausweis — das Mitglied sieht ihn, speichert ihn in der Wallet —, gilt aber noch nicht:

• 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" mit valid_from; der Scan wird trotzdem erfasst;
• das Token trägt denselben Zeitpunkt in nbf: Ein Offline-Scanner kommt allein zur selben Antwort (siehe Einbetten und Ausweisprüfung).

Bei Veranstaltungen nur für Mitglieder antwortet die Teilnahmeprüfung membership_not_yet_valid, wenn die Veranstaltung vor valid_from beginnt; für alles, was später beginnt, meldet sich das Mitglied wie gewohnt an.

Was sich geändert hat (Version 2026-09-19)

Alles additiv, aber sichtbar für alle, die Werte vergleichen:

• status kann rejected sein; verdict kann not_yet_valid sein; der reason von /v1/verify kann ebenfalls not_yet_valid sein;
• pending_reasons ist geordnet (approval vor payment): Die Reihenfolge hatte vorher keine Bedeutung;
• neue Felder admission, payment_open, valid_from, usable; payment_instructions kommt erst, wenn die Zahlung offen ist;
• card ist null — und /v1/me/membership/card, card.svg, card/email, wallet/google antworten 409 not_active —, bis die Mitgliedschaft aktiv ist;
• ein neuer Grund, für eine Veranstaltung nicht teilnahmeberechtigt zu sein: membership_not_yet_valid.