API Terms of Use

These terms govern access to the APIs published on api.tibs.bg. They sit alongside the service agreement between the agency and tibs; where the two differ, the service agreement prevails.

Last updated: 27 July 2026

1. Who may use the API

Access is granted to a tenant of the tibs platform with the public API add-on enabled, and only for that tenant’s own data. A key must not be shared with, resold to, or operated on behalf of a third party without a written agreement with tibs.

2. Keys are credentials

An API key authenticates the tenant. Keep it out of client-side code, public repositories, browser storage, and anything a customer can read. Requests made with a key are attributed to the tenant that owns it, including requests the tenant did not intend.

Report a suspected disclosure to support@tibs.bg and revoke the key from the client portal. Revocation is immediate. tibs may revoke a key without notice where there is evidence of compromise.

3. Source addresses

Keys operate only from IP ranges the tenant has registered and tibs has approved. Approval is manual and may be refused or withdrawn where a range cannot be attributed to the tenant.

4. Fair use and rate limits

Plan limits are published in the reference and enforced per key. Do not circumvent them by rotating keys, distributing traffic across addresses, or retrying in a loop after 429. Honour the Retry-After header.

Use updatedSince for incremental synchronisation rather than re-reading entire collections. Systematic full extraction of the catalogue or contact base beyond what an integration needs is not fair use.

5. Personal data

Contacts and reservations contain personal data of the tenant’s customers. The tenant remains the controller of that data; tibs processes it under the service agreement. When the tenant reads personal data through the API, the tenant is responsible for its lawful basis, storage, retention and deletion in the receiving system.

The contacts:pii and reservations:pii scopes expose identity documents, national identifiers and traveller names. Request them only where the integration genuinely needs them, and do not log the responses.

6. Writes are real

A reservation created through the API is a reservation in the agency’s ERP. Use the test environment and erp_test_ keys for development. Every write requires an Idempotency-Key; reuse it on retry so a network failure does not become a duplicate booking.

7. Availability

The API is provided on the availability terms of the tenant’s service agreement. Planned maintenance is announced in advance where it affects availability. Build for transient failure: retry idempotently with backoff, and do not treat a single failed request as a permanent state.

8. Changes to the contract

Backwards-compatible changes — new endpoints, new optional request fields, new response fields, new values in extensible enumerations — ship without notice. Clients must tolerate them; rejecting unknown response fields is a client defect, not a breaking change.

Breaking changes take a new major version in the path. At most two major versions run at once, and a retired version keeps answering for at least six months after it is marked deprecated.

9. Suspension

tibs may suspend a key or the add-on where use threatens the stability or security of the platform, breaches these terms, or where the service agreement is terminated. Where circumstances allow, notice is given first.

10. Contact and governing law

Questions: support@tibs.bg. These terms are governed by Bulgarian law, and the service agreement between the tenant and tibs governs anything they do not cover.