Welcome to the Standard Interface API documentation.

The Standard Interface API enables seamless integration with WinCloud, allowing external systems and partners to securely exchange hospitality data such as companies, properties, rooms, rates, inventory, reservations, guests, travel agents, master data, and more.

Getting Started

Before using the API, ensure you have:

OAuth client credentials (Client ID and Client Secret)

The audience value for this interface — wincloud

Your Company/Property identifier (where applicable)

Credentials are issued by your RBS administrator. There is no self-service signup, and sandbox and production credentials are separate — request production credentials before go-live.

Available Endpoints

The Standard Interface API is organized into the following functional modules:

Module	Description
Company	Company and property information
Guest	Guest-related master data and operations
Inventory	Retrieve and update room inventory
Master	Common master data such as countries, currencies, payment gateways, and payment methods
Rate	Rate plans, master rates, and rate adjustment templates
Reservation	Reservation retrieval and status management
Room	Room details, room types, tariffs, features, and extra charges
Travel Agent	Active travel agent information

Refer to the individual endpoint documentation for request parameters, sample payloads, and response formats.

Authentication

Every request requires a valid OAuth 2.0 access token issued by RBS Center. There is no alternative route to the data.

The API uses the client credentials grant. Your application exchanges its Client ID and Secret for a short-lived access token, then sends that token on every API call.

Step 1 — Request an access token

client_credentials is the only supported grant type. Always send audience — a token issued without it will be rejected by this interface. The example above uses the sandbox host. Your administrator supplies the RBS Center base URL for your environment — it is not the Standard Interface base URL.

The response returns the token and the permissions granted to it:

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "reservations:read rates:read inventory:read"
}

Step 2 — Call the API

Send the token in the Authorization header on every request:

Permissions

Your token's scope field lists the permissions granted to your application. A permission is <feature>:<operation>, where the operation is read or write. Granting write also allows read.

Feature	Read	Write
Reservations	`reservations:read`	`reservations:write`
Rates	`rates:read`	`rates:write`
Inventory	`inventory:read`	`inventory:write`

A request whose token lacks the required permission is rejected with 403 Forbidden. If an administrator changes your permissions, the change applies to your next token — the token you already hold keeps its existing permissions until it expires.

Managing tokens

Access tokens are short-lived. Read expires_in from the response rather than hardcoding a lifetime.

Keep the token in memory and reuse it for its full life, requesting a replacement shortly before it expires. Do not request a token per API call — the token endpoint is rate limited.

If an API call returns 401 Unauthorized, request one fresh token and retry that call once.

There is no refresh token. To renew access, call the token endpoint again with the same Client ID and Secret.

Response Format

The API returns responses in JSON format.

Success Response

{
  "success": true,
  "data": {}
}

Error Response

{
  "success": false,
  "message": "Description of the error"
}

HTTP Status Codes

Code	Description
200	Success
201	Resource Created
204	No Content
400	Bad Request
401	Unauthorized
403	Forbidden
404	Resource Not Found
409	Conflict
422	Validation Failed
429	Too Many Requests
500	Internal Server Error

Best Practices

Always use HTTPS.

Store your Client Secret in a secret manager. Never commit it to source control, and never expose it in client-side or browser applications.

Reuse access tokens until they are close to expiry.

Validate request payloads before submission.

Handle HTTP status codes appropriately.

Implement retries with exponential backoff for transient failures.

Roadmap

The following enhancements are planned for upcoming releases of the Standard Interface API.

Subscription-based API Access

To support organizations of different sizes and integration needs, the API will introduce a subscription-based access model.

Step 1 — Default Access

Every organization will be assigned a Base Tier by default.

This tier provides standard API usage limits suitable for most integrations.

Step 2 — Custom Subscription Tiers

Organizations requiring higher API capacity can be assigned a Custom Tier.

Each custom tier allows administrators to configure API usage limits based on business requirements.

Step 3 — Tier-based API Limits

Each subscription tier will define independent Read and Write limits for supported API modules, including:

Reservations

Rates

Inventory

All credentials belonging to an organization will automatically use the limits configured for that organization's assigned tier.

Step 4 — Usage & Monitoring

Administrators will be able to:

View API usage

Monitor consumption against allocated limits

Support

If you experience any issues or have integration questions, please contact the WinCloud Support Team.

Last Updated: August 2026

Integration Guide

Getting Started#

Available Endpoints#

Authentication#

Step 1 — Request an access token#

Step 2 — Call the API#

Permissions#

Managing tokens#

Response Format#

Success Response#

Error Response#

HTTP Status Codes#

Best Practices#

Roadmap#

Subscription-based API Access#

Step 1 — Default Access#

Step 2 — Custom Subscription Tiers#

Step 3 — Tier-based API Limits#

Step 4 — Usage & Monitoring#

Support#