API Endpoints
All endpoints require authentication and are prefixed with/v3/order:
POST /v3/order/psc/appointment/availability- Get available time slotsPOST /v3/order/{order_id}/psc/appointment/book- Book an appointmentPATCH /v3/order/{order_id}/psc/appointment/reschedule- Reschedule an appointmentPATCH /v3/order/{order_id}/psc/appointment/cancel- Cancel an appointmentGET /v3/order/{order_id}/psc/appointment- Get appointment detailsGET /v3/order/psc/appointment/cancellation-reasons- Get cancellation reasons
Error Handling
Environment Differences
⚠️ Important: Currently, error behavior differs between sandbox and production environments:
Recommendation: For now, handle both 400 and 404 responses as potential slot-unavailability scenarios.
Frequently Asked Questions
Q: Do I need to parse error messages to distinguish between different 400 errors?
Yes. Since multiple error types return 400 status codes, you must examine the error message content to determine the appropriate handling:- Time in the past:
"This appointment slot is no longer available. Please select a new time."→ Select new slot - Invalid booking key:
"Invalid booking key format"→ Fix request - Missing parameters:
"radius must be provided when using zip_code"→ Fix request - Order state issues:
"Order is not in a state that allows booking..."→ Contact support
Error Categories
Slot Unavailability Errors
The user should select a different time slotInput Validation Errors
Fix the request parametersOrder State Errors
Order workflow or business logic issuesAppointment Management Errors
Appointment-specific business rulesAuthorization Errors
Access control issuesService Availability Errors
System configuration or availabilityTesting Error Scenarios
Sandbox Testing
- Most validation errors can be tested in sandbox
- Slot conflicts cannot be reliably tested (mock client always succeeds)
- Use invalid parameters to test input validation
Production Testing
- Test with caution using real appointments
- Slot conflicts will return actual 404 errors from Quest
- Time-based errors can be tested with past dates
Quest API Limitations
- Timeout: 15 seconds read timeout, 5 seconds connection timeout
- Slot availability: Real-time, can change between availability check and booking
- Mock client: Doesn’t simulate all real-world scenarios
- Rate limiting: Standard Quest API rate limits apply