The VXNE protocol.

System Architecture

VXNE runs as three logical layers. Each layer has a single responsibility and a defined contract with adjacent layers.

L1 — Systems of Record (Sources)

Your existing infrastructure: Mews, Jonas, Lightspeed, ANPR cameras, ForeTees, custom systems. These remain untouched. VXNE integrates by subscribing to their event streams via webhook, polling endpoint, or Apache Camel route — whichever the source supports.

L2 — The Operating Layer (VXNE)

The translation shell. Responsibilities:

• Webhook ingestion (Edge Functions, regional)
• Event normalization to canonical schema
• Cross-system correlation (license plate → member ID → today's booking → preferences)
• Role-based routing engine
• Member Timeline state machine
• Push delivery to L3 interfaces
• Webhook ingestion (Edge Functions, regional)
• Event normalization to canonical schema
• Cross-system correlation (license plate → member ID → today's booking → preferences)
• Role-based routing engine
• Member Timeline state machine
• Push delivery to L3 interfaces

L3 — Actionable Interfaces

Role-aware surfaces consumed by staff. Implemented as Progressive Web App (PWA) for cross-platform compatibility without App Store distribution. Supports iOS, Android, watchOS via Web Push, and desktop browsers as second-screen displays.

Core Concepts

Member Timeline

The Member Timeline is the canonical VXNE data structure. For each member, VXNE maintains a chronological sequence of contextualized events sourced from connected systems. The timeline is the single read model that all L3 interfaces consume, filtered by role.

Event Card

The atomic unit of L3 interfaces. Each event card represents one actionable signal from the timeline. Cards have explicit state: pending, acknowledged, or completed. State transitions are role-scoped — a card acknowledged by a valet remains pending for a receptionist if both are recipients.

Role Routing

Each event type maps to a set of roles. An ANPR arrival event routes to the valet role; a kitchen ticket routes to F&B runners. Routing rules are configurable per club and per event type. VXNE does not broadcast — every push has a deterministic recipient set.

Webhook Schema

All inbound events to VXNE follow a normalized envelope. Source systems either emit this format natively or are wrapped by a VXNE-maintained adapter.

{
  "event_id": "evt_2N4kP9xQrL8aWd",
  "event_type": "member.arrival",
  "source_system": "anpr_camera_gate_01",
  "club_id": "club_thedutch",
  "timestamp": "2026-05-14T09:22:14.382Z",
  "member_ref": {
    "id": "mbr_jansen_4421",
    "matched_by": "license_plate",
    "confidence": 0.98
  },
  "payload": {
    "license_plate": "GH-892-T",
    "location": "main_gate",
    "vehicle_type": "sedan"
  },
  "enrichment": {
    "member_name": "Dhr. Jansen",
    "member_tier": "premium",
    "todays_booking": {
      "type": "tee_time",
      "time": "10:00",
      "flight_id": "flt_8821"
    },
    "locker": "14",
    "preferences": ["americano", "macallan_18"]
  },
  "routing": {
    "roles": ["valet", "caddiemaster", "locker_attendant"],
    "priority": "standard"
  }
}

The enrichment field is populated by VXNE at ingestion time by joining the inbound event with member profiles, today's bookings, and historical preferences. The source system never produces enrichment data — that is VXNE's responsibility.

Event Types

VXNE recognizes the following event categories. Each event type has a canonical schema. Custom event types can be defined per club.

Member Events

• member.arrival — Member detected entering premises
• member.checkin — Member formally checked in (PMS)
• member.departure — Member detected leaving
• member.vip_flag — VIP status triggered for current visit
• member.arrival — Member detected entering premises
• member.checkin — Member formally checked in (PMS)
• member.departure — Member detected leaving
• member.vip_flag — VIP status triggered for current visit

Booking Events

• booking.confirmed — New reservation confirmed
• booking.status_change — Status update (e.g., tee time finished)
• booking.modified — Time or party-size change
• booking.confirmed — New reservation confirmed
• booking.status_change — Status update (e.g., tee time finished)
• booking.modified — Time or party-size change

Commerce Events

• order.placed — POS order created
• order.completed — Payment processed
• order.special_request — Item with member preference
• order.placed — POS order created
• order.completed — Payment processed
• order.special_request — Item with member preference

Operational Events

• capacity.threshold — Occupancy threshold reached
• staff.task_acknowledged — Card state transition
• system.degraded — Upstream system unreachable
• capacity.threshold — Occupancy threshold reached
• staff.task_acknowledged — Card state transition
• system.degraded — Upstream system unreachable

API Reference

VXNE exposes a REST API for configuration, timeline queries, and webhook registration. Authentication uses bearer tokens scoped per club.

Webhook Registration

curl https://api.vxne.io/v1/sources \
  -H "Authorization: Bearer $VXNE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source_type": "anpr_camera",
    "source_id": "gate_01",
    "webhook_url": "https://api.vxne.io/v1/ingest/anpr",
    "auth_method": "hmac_sha256",
    "secret": "[generated]"
  }'

Query Member Timeline

curl https://api.vxne.io/v1/members/mbr_jansen_4421/timeline \
  -H "Authorization: Bearer $VXNE_API_KEY" \
  -G \
  -d "from=2026-05-14T00:00:00Z" \
  -d "limit=50"

Configure Role Routing

curl -X PUT https://api.vxne.io/v1/clubs/thedutch/routing \
  -H "Authorization: Bearer $VXNE_API_KEY" \
  -d '{
    "rules": [
      {
        "event_type": "member.arrival",
        "roles": ["valet", "caddiemaster"],
        "priority": "standard"
      }
    ]
  }'

Security & GDPR

VXNE processes personal data of club members. Compliance with GDPR is foundational, not retrofitted.

Data Residency

• All event ingestion endpoints hosted in EU (Frankfurt, Amsterdam)
• Database hosted on EU-region infrastructure
• No data egress to non-adequate jurisdictions
• All event ingestion endpoints hosted in EU (Frankfurt, Amsterdam)
• Database hosted on EU-region infrastructure
• No data egress to non-adequate jurisdictions

Data Masking

Sensitive PII (full names, license plates, contact details) is masked at the L3 interface layer based on role. A valet sees "Dhr. Jansen" — never the full record. A receptionist sees more context. The GM dashboard never shows individual transactional data without explicit query.

Consent-Based Triggers

Members may opt out of operational recognition (e.g., wishing to remain anonymous to staff). When opted out, VXNE suppresses enrichment and routes events with minimal personalization.

Audit Trail

Every event ingested, every routing decision, and every staff acknowledgment is logged with cryptographic chain. Audit logs are retained 12 months by default, configurable per club.

Scalability Model

VXNE scales horizontally per club. Each club operates as an isolated tenant with dedicated event streams, routing rules, and timeline state.

Why In-House Builds Fail

Clubs that build operational layers in-house face three structural problems:

• Source system APIs change — every Jonas, Mews, or Lightspeed update potentially breaks integration
• One developer maintaining 10+ integrations is operationally untenable
• Each new event source requires net-new integration work, not configuration
• Source system APIs change — every Jonas, Mews, or Lightspeed update potentially breaks integration
• One developer maintaining 10+ integrations is operationally untenable
• Each new event source requires net-new integration work, not configuration

VXNE absorbs this maintenance burden across our customer base. When Jonas updates their webhook schema, the adapter is updated once. Every VXNE club benefits.

SLA & Uptime

Pilot deployments include the following service guarantees:

• Event ingestion availability: 99.9% monthly
• Event-to-push latency: under 1000ms p95
• Member Timeline query latency: under 250ms p95
• Incident response: 4 hours business hours, 24 hours off-hours
• Event ingestion availability: 99.9% monthly
• Event-to-push latency: under 1000ms p95
• Member Timeline query latency: under 250ms p95
• Incident response: 4 hours business hours, 24 hours off-hours

Production deployments are negotiated per contract. Multi-property Custom deployments include dedicated infrastructure with stricter SLAs.