Overview

This API allows partners to publish their products on travelstride website, update existing listings, and control their inventory. Get started by requesting access. To do so simply contact here.

Current Version

By default, all requests to https://api.travelstride.com receive the v1 version of the REST API.

Schema

All API access is over HTTPS, and accessed from the https://api.travelstride.com. All data is sent and received as JSON.

All timestamps return in ISO 8601 format. For example:

1995-11-30T08:00:00+0300

Authentication

Access to this API requires authentication. Requesting any endpoint with incorrect or wrong credentials will result in 401 Unauthorized.

Use HTTP Authentication with the following Authentication Schemes:

  • HTTP Basic
  • HTTP Bearer with JWT Token

    This authentication scheme requires a single JWT Token to be sent in the HTTP Authorization header as a "Bearer Token".

    You can obtain a token by sending your username (email) and password as application/x-www-form-urlencoded data in a POST request to the token endpoint.

    Step 1: Obtain Access Token

    POST /v1/login/access-token HTTP/1.1
    Host: api.travelstride.com
    Content-Type: application/x-www-form-urlencoded
    
    username=user@example.com&password=your_secret_password

    Example using cURL:

    curl -X POST https://api.travelstride.com/v1/login/access-token \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d "username=user@example.com&password=your_password"

    The server will respond with a JSON object containing your access_token.

    Step 2: Use the Token

    Once you have the access token, include it in the Authorization header of your subsequent API requests, prefixed with "Bearer ".

    GET /v1/some-protected-endpoint HTTP/1.1
    Host: api.travelstride.com
    Authorization: Bearer YOUR_JWT_TOKEN_HERE

    Example using cURL:

    curl -X GET "https://api.travelstride.com/v1/universal/trips" \
    -H "Authorization: Bearer YOUR_JWT_TOKEN_HERE"

Rate Limiting

To ensure API stability and fair usage for all users, we enforce rate limiting on all endpoints. Our API limits are generally based on the client IP address.

If you exceed a rate limit, the API will respond with an HTTP 429 Too Many Requests error.

Each API response includes the following headers to help you track your current rate limit status:

  • X-RateLimit-Limit: The total number of requests allowed in the current time window.
  • X-RateLimit-Remaining: The number of requests remaining in the current window.
  • X-RateLimit-Reset: The time at which the current window resets, in UTC epoch seconds.
  • Retry-After: The number of seconds to wait before making a new request when you have been rate limited.

We recommend that your application code checks for these headers and implements a retry mechanism with backoff if a 429 status code is received.

Example

You can test the rate limiting by making requests to the /v1/utils/rate-limit-test endpoint, which is limited to 5 requests per minute. Using cURL with the -i flag will show the response headers.

A successful request under the limit returns a 200 OK status and the current rate limit headers:

$ curl -i "https://api.travelstride.com/v1/utils/rate-limit-test"

HTTP/1.1 200 OK
x-ratelimit-limit: 5
x-ratelimit-remaining: 4
x-ratelimit-reset: 1753131893
retry-after: 60
...

{"message":"Success","timestamp":1753131862.6310167}

After exceeding the 5 requests in a minute, the API will return a 429 Too Many Requests error. The Retry-After header indicates you should wait 26 seconds before trying again.

$ curl -i "https://api.travelstride.com/v1/utils/rate-limit-test"

HTTP/1.1 429 Too Many Requests
x-ratelimit-limit: 5
x-ratelimit-remaining: 0
x-ratelimit-reset: 1753131893
retry-after: 26
...

{"error":"Rate limit exceeded: 5 per 1 minute"}

We recommend that your application code checks for these headers and implements a retry mechanism with backoff if a 429 status code is received.