Skip to main content

Guest Charging with ad_hoc Tokens

The ad_hoc strategy creates a temporary token for a booking. No pre-existing driver account is needed. This is ideal for:

  • Guest charging for visitors or contractors
  • One-off bookings where creating a full account is overkill
  • Trial users testing your platform

How It Works​

  1. Your system calls POST /bookings with token_strategy: "ad_hoc" — no customer_id needed
  2. EV Suite auto-creates a temporary RFID token for this booking
  3. The response includes the token details — distribute these to the driver
  4. The driver uses the temporary token (or a QR code) at the charger

Create an ad_hoc Booking​

curl -s -X POST https://api.petitmonde.energy/api/v1/client/bookings \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "location_id": "DE-ENB-E123456",
    "evse_uid": "DE*ENB*E123456*1",
    "reservation_start": "2026-02-10T14:00:00Z",
    "reservation_end": "2026-02-10T16:00:00Z",
    "external_id": "guest-booking-789",
    "token_strategy": "ad_hoc"
  }' | jq .

No customer_id or token_id is required — the system creates everything automatically.

Distributing the Token​

The booking response includes a temporary token. Send it to the guest via:

  • SMS or email with the token UID
  • A QR code they can scan at the charger
  • Your app's push notification

The token is valid only for the booking's time window and automatically expires after.

Limitations​

  • Temporary tokens cannot be reused across bookings
  • The token is tied to the specific EVSE and time window
  • No driver history is associated with ad_hoc bookings

When to Use ad_hoc vs. driver_token​

ScenarioStrategy
Registered driver with RFID carddriver_token
Visitor needs one-time accessad_hoc
Contractor working on-site for a weekad_hoc (one per day)
New user trial before full onboardingad_hoc