Developer Documentation
Developers
API overview, authentication model, rate limits, and error catalog for the Holiday Lydian platform.
Current status
The HTTP API described here is first-party: it powers our own web and mobile clients and is authenticated with a same-origin session. A public API-key programme and a published SDK are on our roadmap and are not generally available yet. If you are building an integration, contact us and we will scope access with you.
API overview
The platform exposes a JSON-over-HTTPS API. Endpoints follow REST conventions: resources are addressed by path, results are returned as JSON, and standard HTTP status codes signal success or failure. All traffic is served over TLS from the holiday.ailydian.com origin.
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /api/health | Service health check. |
| GET | /api/tours | List and filter tours by destination. |
| GET | /api/search/hotels | Search hotels by destination and dates. |
| GET | /api/transfers/search | Search airport and intercity transfers. |
| GET | /api/search/cars | Search car-rental availability. |
Authentication
Today, authenticated endpoints rely on a same-origin session cookie issued at sign-in. Because the clients are first-party, requests carry the session automatically and no API key is required or accepted. Cross-site requests are rejected and mutating requests are CSRF-protected.
Roadmap: Long-lived API keys and OAuth-style scoped tokens for third-party integrations are planned. When available they will be issued per organisation with per-scope permissions.
Rate limits
Requests are rate limited per client to protect platform stability. When a client exceeds its allowance the API responds with HTTP 429 and a Retry-After header indicating when to try again. Build clients that back off and retry rather than hammering the endpoint.
- A 429 response means slow down — honour the Retry-After header.
- Use exponential backoff with jitter for retries.
- Cache read responses where possible; catalog data changes infrequently.
Error catalog
Errors return a non-2xx HTTP status and a JSON body with a stable machine-readable code and a human-readable message. Match on the code, not the message text.
| Status | Code | Meaning |
|---|---|---|
| 400 | bad_request | The request was malformed or missing required parameters. |
| 401 | unauthenticated | No valid session was supplied; sign in first. |
| 403 | forbidden | Authenticated, but not allowed to access this resource. |
| 404 | not_found | The requested resource does not exist. |
| 405 | method_not_allowed | The HTTP method is not supported on this endpoint. |
| 422 | validation_error | The request body failed validation; see the message for details. |
| 429 | rate_limited | Too many requests — retry after the interval in Retry-After. |
| 500 | internal_error | An unexpected error occurred on the server. |
Example request & response
Request
curl -sS 'https://holiday.ailydian.com/api/tours?destination=antalya&limit=2' \
-H 'Accept: application/json'Response
{
"success": true,
"count": 2,
"results": [
{
"slug": "antalya-city-tour",
"title": "Antalya City Tour",
"destination": "antalya",
"priceFrom": 39,
"currency": "USD"
}
]
}The exact field set varies by endpoint. Fields may be added over time; write clients that ignore unknown fields.
SDKs
There is no published client SDK today. Any language with an HTTP client can call the API directly. An official SDK will follow the public API-key programme on the roadmap.
Contact
Planning an integration or need early API access? Email us and we will help scope it.
developers@holiday.ailydian.com
Supplying inventory instead? See supplier onboarding.