Konto- und Rollenprüfung
Kein Vertrauen in übergebene Kundennummern. Autorisierung auf jedes Objekt und jede Mitarbeiteraktion anwenden.
Eine API.
Website, Portal und App.
Ressourcen, Authentifizierung und Transaktionsanforderungen für eine gemeinsame Kundenplattform.
Planungsstand V59: Die Datenfelder, Endpunkte und Rollen sind Entwürfe, keine vorhandene Perfex-Funktion. Vor der Implementierung müssen installierte Perfex-Version, Module, Datenbankschema und reale Zahlungsanbieter geprüft werden.
Vorgeschlagene Endpunkte
Routen und Antwortfelder sind API-Designvorschläge, nicht nachgewiesene Perfex-Endpunkte.
| Methode | Route | Rolle | Schutzanforderung |
|---|---|---|---|
| GET | /v1/me/events | Kunde | Eigene Events; Pagination |
| GET | /v1/me/event-orders/{id} | Kunde (Eigentümer) | Bestellung und autorisierte Rechnung referenzieren |
| POST | /v1/event-orders | Angemeldeter Kunde | Bestellung reservieren; Idempotency-Key |
| POST | /v1/event-orders/{id}/checkout | Kunde (Eigentümer) | Perfex-Rechnungsworkflow; keine direkte Bezahlmarkierung |
| GET | /v1/me/event-tickets | Kunde | Nur eigene Tickets |
| GET | /v1/me/event-tickets/{id} | Kunde (Eigentümer) | Ticket und erlaubte Teilnehmerdaten |
| POST | /v1/staff/events/{id}/checkins | Check-in-Mitarbeitende | Ticket validieren und atomar einchecken |
| GET | /v1/staff/events/{id}/capacity | Eventorganisation | Kontingent und reservierte Kapazität |
| POST | /v1/internal/perfex-payment-events | Interner Dienst | Verifizierter signierter Server-zu-Server-Eingang |
Beispiel: Reservierung mit mehreren Kategorien
POST /v1/event-orders
Authorization: Bearer <access_token>
Idempotency-Key: 9c1b7e2d-demo-only
Content-Type: application/json
{
"event_id": "evt_demo_1",
"items": [
{"ticket_type_id": "type_standard", "quantity": 2},
{"ticket_type_id": "type_digital", "quantity": 1}
]
}
201 Created
{
"order_id": "ord_demo_1",
"state": "reserved",
"reservation_expires_at": "2026-12-05T15:15:00+01:00",
"currency": "CHF",
"total_minor": 11700
}Der gezeigte Zeitpunkt und Betrag sind reine Demo-Werte. Tatsächliche Preisberechnung, Kontingentprüfung und Reservation erfolgen serverseitig.
Pflichtanforderungen für jede API
Idempotenz und Audit
Schreibende Anfragen gegen Wiederholung schützen; sicherheitsrelevante Aktionen revisionsfähig protokollieren.
Versionierung und Monitoring
Versionierte API, Rate-Limits, Paginierung, definierte Fehlercodes, korrekte Zeitzonen und Monitoring.
Abnahmetests vor Produktivstart
Zwei Kunden, getrennte Daten
Kunde A darf keine Bestellung, Rechnung oder Tickets von Kunde B sehen oder verändern. Negative API-Tests sind Pflicht.
Parallelbuchungen unter Last
Bei nur einem Restticket und mehreren gleichzeitigen Anfragen darf genau eine Reservation erfolgreich sein.
Wiederholte Zahlungsereignisse
Zweimal gelieferte Payment-Webhooks dürfen weder doppelte Tickets noch mehrfach gebuchte Zahlungen auslösen.
Check-in und Rollen
Unberechtigte Mitarbeitende werden abgewiesen, doppelte Scans erzeugen keinen zweiten Eintritt und alle Aktionen werden protokolliert.
Ein Kundenportal bleibt die Grundlage.
Website und App sind Benutzeroberflächen. Kundenbestand, Rechnung und Zugang zu Eventdaten werden zentral über Perfex und geprüfte Erweiterungen gesteuert.