API Policy of qibb services and flows

API Design

qibb is designed and developed with an API-first approach. All its functionality is exposed via well-defined RESTful API endpoints that are fully described as OpenAPIs.

The RESTful endpoints can be used for request-response based communication to perform typical CRUD operations on resources as well as to send system instructions.

All endpoints share a common API design, including the following key aspects:

• Documentation and machine-readable interfaces based on OpenAPI Specification

• Endpoint-level versioning enables a clear API lifecycle and precise change management, including deprecation and introduction of endpoints.

• OpenID/OAuth 2.0 Token based security and Role-based Access Control on endpoint level

• Common parameters for pagination, filtering, sorting and field masking for efficient data retrieval of resource collections

Endpoint Deprecation

Our versioning at the endpoint level ensures a clear API lifecycle and effective change management, allowing for fine-grained deprecation of old endpoints and the introduction of new ones.

• The version is indicated with a "vX" segment in the URL path, for Example: /v1/.

• Deprecated endpoints will be removed no earlier than 3 releases after their deprecation, providing consumers sufficient time to react and adapt to the changes.

Retry Policy

To ensure reliable communication, qibb's API Gateway has built-in retry handling for incoming HTTPS API requests for all qibb services and your flows. When the gateway detects a failed request, such as a timeout, server error or downtime, it catches the response and resends the request multiple times.

If any retry attempt succeeds, the gateway forwards the successful response to the client.

Rate Limit Policy

Any API endpoint provided by qibb is safeguarded with rate limiting measures to enhance the availability and resilience of your services. If you exceed the rate limit for a particular service, you will receive a response containing Status code 429.