Vehicle Validation
Vehicle validation is the process that determines whether a vehicle can be rented by a customer. When a customer attempts to scan a vehicle or start a ride, the system performs multiple validation checks to ensure the vehicle is safe, available, and properly configured.
Validation Overview
When Validation Occurs
Vehicle validation happens at several points:
| Trigger | Purpose |
|---|---|
| QR Code scan | Check if vehicle can be unlocked |
| Map tap | Verify vehicle is available to rent |
| Ride start | Final eligibility check before unlocking |
| During ride | Ongoing checks (battery, zones) |
| Ride end | Verify ending location is valid |
Validation Response
Each validation returns:
- Success: Vehicle is available, ride can proceed
- Failure: Vehicle cannot be rented, with reason
Validation Checks
The system performs multiple checks in sequence. All must pass for a vehicle to be available.
1. Vehicle Exists
Check: Does the vehicle exist in the system?
| Result | Meaning |
|---|---|
| Pass | Vehicle found by QR code or ID |
| Fail | Unknown vehicle, QR code invalid |
Common failures:
- Invalid or corrupted QR code
- Vehicle deleted from system
- Vehicle from different environment (staging vs production)
2. Status Check
Check: Is the vehicle in an available status?
| Status | Can Rent? | Notes |
|---|---|---|
available | ✅ Yes | Normal rental status |
available_hidden | ❌ No | Hidden from customers |
in_use | ❌ No | Currently being rented |
maintenance | ❌ No | Under repair |
offline | ❌ No | No IoT connection |
not_ready | ❌ No | Not configured for use |
charging | ❌ No | Battery charging |
transportation | ❌ No | Being relocated |
storage | ❌ No | In long-term storage |
Available Hidden
The "Available (Hidden)" status allows operators to hide vehicles from customers while keeping them technically rentable for staff testing or special cases.
3. Active Ride Check
Check: Does the vehicle already have an active ride?
| Result | Meaning |
|---|---|
| Pass | No active ride on vehicle |
| Fail | Vehicle currently in use |
This prevents double-booking even if status wasn't properly updated.
4. Battery Level Check
Check: Does the vehicle have sufficient battery?
| Configuration | Description |
|---|---|
| Minimum battery | Subaccount-defined threshold |
| Typical value | 15-25% |
| Override | Staff rides may bypass |
Example: If minimum is set to 20%, a vehicle at 18% battery fails validation.
5. IoT Device Check
Check: Is there a working IoT device attached?
| Result | Meaning |
|---|---|
| Pass | IoT device linked and communicating |
| Fail | No device or device offline |
Vehicles without IoT devices cannot be rented because:
- Cannot send unlock command
- Cannot track location during ride
- Cannot verify ride end
6. Location Validation
Check: Is the vehicle in an allowed zone?
| Zone Type | Effect on Validation |
|---|---|
| Service area | Must be inside to rent |
| No-ride zone | Cannot start ride here |
| Parking zone | No effect on start |
| Slow zone | No effect on validation |
Zone Configuration
If no service area zones are configured, location validation may be skipped. Configure zones appropriately for your market.
7. Subaccount Check
Check: Does the customer have access to this subaccount?
| Result | Meaning |
|---|---|
| Pass | Customer can rent from this operator |
| Fail | Customer not authorized for this fleet |
This applies when:
- Multiple operators share an app
- Customer signed up with a different operator
- Regional restrictions apply
8. Customer Eligibility
Check: Is the customer allowed to rent?
| Check | Description |
|---|---|
| Account status | Not suspended or banned |
| Payment method | Valid payment on file |
| Age verification | Meets minimum age (if required) |
| Active ride limit | Not exceeding concurrent ride limit |
| Outstanding balance | No unpaid balances (if configured) |
Validation Messages
Success Response
When validation passes:
{
"valid": true,
"vehicle": {
"id": "vehicle-uuid",
"vehicle_number": "VH-001",
"battery_level": 85,
"model": "Levy Max"
},
"pricing": {
"unlock_fee": 1.00,
"per_minute_rate": 0.35
}
}
Failure Response
When validation fails:
{
"valid": false,
"error_code": "VEHICLE_LOW_BATTERY",
"message": "This vehicle's battery is too low. Please try another vehicle.",
"details": {
"current_battery": 12,
"minimum_required": 20
}
}
Common Error Codes
| Code | User Message | Cause |
|---|---|---|
VEHICLE_NOT_FOUND | "Vehicle not found" | Invalid QR/ID |
VEHICLE_UNAVAILABLE | "Vehicle is not available" | Wrong status |
VEHICLE_IN_USE | "Vehicle is currently in use" | Active ride exists |
VEHICLE_LOW_BATTERY | "Battery too low" | Below minimum |
VEHICLE_OFFLINE | "Vehicle is offline" | No IoT connection |
OUTSIDE_SERVICE_AREA | "Outside service area" | Location invalid |
CUSTOMER_SUSPENDED | "Account suspended" | Customer issue |
PAYMENT_REQUIRED | "Add payment method" | No valid payment |
RIDE_LIMIT_REACHED | "Maximum rides reached" | Too many active rides |
Configuration Options
Subaccount Settings
Each subaccount can configure validation rules:
| Setting | Description | Default |
|---|---|---|
| Minimum battery | Lowest battery % for rentals | 20% |
| Require IoT | Must have working IoT device | Yes |
| Check zones | Validate location against zones | Yes |
| Max active rides | Concurrent rides per customer | 1 |
| Allow hidden vehicles | Staff can rent hidden vehicles | Yes |
Override Capabilities
Certain roles can bypass validation:
| Role | Can Override |
|---|---|
| Super Admin | All checks |
| Admin | Battery, status |
| Fleet Manager | Battery, status |
| Service Tech | Battery (for testing) |
| Customer | None |
Real-Time Availability
Map Display
On the customer app map:
- Only validated-available vehicles appear
- Vehicles failing any check are hidden
- Updates in real-time as conditions change
Availability Calculation
The system continuously evaluates:
Available = Status is 'available'
AND Battery >= Minimum
AND No active ride
AND IoT connected
AND In service area
Troubleshooting Validation
"Vehicle Not Available"
Steps to diagnose:
- Check vehicle status in dashboard
- Review battery level - is it above minimum?
- Check for active rides on the vehicle
- Verify IoT device is linked and communicating
- Check location - is vehicle in service area?
"Vehicle Not Found"
Possible causes:
- QR code damaged - regenerate and replace
- Wrong environment - staging vs production
- Vehicle deleted - check deleted vehicles
- Subaccount mismatch - vehicle in different subaccount
Customer Can't Rent Any Vehicle
Check customer-side issues:
- Account status - suspended or banned?
- Payment method - valid card on file?
- Outstanding balance - unpaid charges?
- Verification - age/ID verification needed?
- Active rides - at maximum limit?
Validation Passes But Unlock Fails
Validation and unlock are separate:
- Validation checks eligibility (database)
- Unlock sends command to IoT device
If validation passes but unlock fails:
- IoT device may be offline (stale status)
- Command may have timed out
- Device may have hardware issue
API Reference
Validate Vehicle
POST /api/vehicles/{id}/validate
Request:
{
"customer_id": "customer-uuid",
"location": {
"latitude": 40.7128,
"longitude": -74.0060
}
}
Response (success):
{
"valid": true,
"vehicle_id": "vehicle-uuid",
"checks_passed": [
"status",
"battery",
"iot_device",
"no_active_ride",
"service_area",
"customer_eligible"
]
}
Response (failure):
{
"valid": false,
"error_code": "VEHICLE_LOW_BATTERY",
"message": "Battery level is below minimum requirement",
"failed_check": "battery",
"details": {
"current": 15,
"required": 20
}
}
Check Vehicle Availability (Lightweight)
GET /api/vehicles/{id}/available
Returns simple boolean for map display:
{
"available": true
}
Best Practices
For Operators
- Set appropriate minimums: Balance availability with safety
- Monitor failed validations: Track patterns in failures
- Keep zones updated: Ensure service areas are accurate
- Regular status audits: Verify statuses match reality
For Integration
- Handle all error codes: Provide helpful user messages
- Cache appropriately: Availability changes frequently
- Implement retries: Transient failures may resolve
- Log validation results: Useful for debugging
For Customer Experience
- Clear error messages: Help customers understand issues
- Suggest alternatives: "Try another nearby vehicle"
- Real-time updates: Remove unavailable vehicles promptly
- Explain requirements: Battery minimums, service areas
Need Help?
For validation configuration or troubleshooting assistance, contact support@levyelectric.com.