RELEX Solutions Transactions API

openapi: 3.2.0
info:
  version: v4.28.3
  description: "# API specification\n\nThis documentation describes the data resources and technical details available for the RELEX Data API. \n\nIn short:\n\n* The data resources are divided by tags according to data type. \n* The payload contents of individual resources are described in detail with example payload data.\n\n> ⚠️ **All API requests must be made over HTTPS**\n>\n> Calls made over plain HTTP fail and return HTTP Status Code 400 Bad Request.\n\n## Glossary\n\n* A **resource** is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. In practice, *the resource* most often maps to a corresponding database table, but not always.\n* An **environment** (also tier) is a computer system or set of systems in which a computer program or software component is deployed and executed. The most common setup for RELEX Data API clients is to have *user-acceptance-test* and *production* environments.\n\n## REST as an architectural style\n\nREST stands for Representational State Transfer which is an architectural pattern describing how distributed systems can expose a consistent interface through the web. When people use the term *REST API*, they are generally referring to an API accessed via HTTP protocol at a predefined set of URLs.\n\nThe RELEX Data API is built around these concepts and has predictable resource-oriented URLs, accepts JSON-encoded requests, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and HTTP verbs.\n\nThe biggest difference to traditional record-oriented REST APIs is that the RELEX Data API can ingest multiple records into a single HTTP request. This allows the clients to bundle individual changes into small batches and send them in one request.\n\nThis typically increases performance and reduces the overhead of handling individual requests. This style is prevalent in the RELEX Data API regardless of the HTTP verb used.\n\n> ⚠️ **We strongly recommend using micro-batches (small batches of records) whenever possible.**\n> \n>Micro-batches provide significantly better throughput, reduce request overhead, and help avoid hitting rate limits during high-volume updates.\n\n## OpenAPI Specification\n\nThe API is documented in **OpenAPI format** and is based on the Data API provided by RELEX. For more information on OpenAPI format, refer to the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md). This documentation is created by using the [ReDoc](https://github.com/Rebilly/ReDoc) tool.\n\n## Continuous data streams\n\nThe RELEX Data API is designed to receive data as a continuous stream. The API allows the clients to send the data whenever changes happen, either one record at a time or in batches of records. Hence, there are no explicit start and end notions for a set of data.\n\nInstead, data is processed as it arrives, whenever the backend systems deem it appropriate. While typically the data is processed in the order it arrives, due to the nature of distributed systems, RELEX may process data received in subsequent requests in a different order than originally sent.\n\n> ⚠️ **Avoid making immediate subsequent updates to the same record**\n>\n> We discourage making numerous mutative API calls to the same records in rapid succession, in other words, POST and DELETE requests.\n>\n> Instead, we recommend batching the same records into one request. Making quick consecutive updates for the same record may cause a race condition that can cause the data to get out of sync between the client and RELEX.\n\n> \n> ⚠️ **Using micro-batches is the preferred pattern for continuous data streams.**\n> \n> Sending multiple small updates in one batch reduces the number of API calls, minimizes the chance of race conditions, and significantly lowers the likelihood of hitting rate limits during heavy traffic.  \n> Single-record requests should be reserved for low-volume or exceptional cases only.\n\n### Cross-endpoint record coordination\n\nThe RELEX Data API does not coordinate supplied records across endpoints. This means that if two records are supplied to two distinct endpoints, the API might make them available for target applications to consume in either order (records within one endpoint will always be made available in the order they were supplied to the API). If the two records are somehow related to each other and no additional steps were taken, the end result could depend on which record is consumed first. To prevent this, target applications might take additional steps to guarantee identical results regardless of inter-topic consumption order. Using UPSERT logic (i.e. update if exists, otherwise create) is a common way to accomplish this.\n\nMany endpoints are connected to each other in the data models of target applications. For example, the Product Locations endpoint expects both a product code and a location code. The given codes are typically used to link the supplied record to the corresponding product and location in the target application. Such links are only possible if the referenced records exist. To remove the dependency on consumption order, an incoming product-location record might result in automatic creation of the referenced product and location if they do not already exist so that the needed references are in place. The same principle applies to many other endpoints. When automatic reference creation creates an entry, typically only the required fields and fields with default values are populated.\n\n## JSON format\n\nThe RELEX Data API uses JSON as the format for data serialization. The JSON payload of the API has a root-level object that contains a meta-object and data array element. Requests need to define a Content-Type header and be set to *application/json*.\n\nAll resources have a defined schema, and the details of each resource can be examined in the resource specifications in this document.\n\n## Dates, times and timestamps\n\nDates, times and timestamps in RELEX Data API generlly follows the Date and Times JSON Schema format which is based on [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339.html) standard, unless otherwise specified (for example endpoints with `time` fields are usually accepting only `hh:mm`).\n\n## Localization of names\n\nIf the consumer application supports localization of names, the corresponding name for a specific language can be set by adding one of the following fields to the schema.\n\n| Language             | Endonym               | field_name     |\n|----------------------|-----------------------|----------------|\n| Czech                | Čeština               | name_cs        |\n| Danish               | Dansk                 | name_da        |\n| German               | Deutsch               | name_de        |\n| Greek                | Ελληνικά              | name_el        |\n| English              | English               | name_en        |\n| Spanish              | Español               | name_es        |\n| Estonian             | Eesti keel            | name_et        |\n| Finnish              | Suomeksi              | name_fi        |\n| French               | Français              | name_fr        |\n| Croatian             | Hrvatski              | name_hr        |\n| Hungarian            | Magyar nyelv          | name_hu        |\n| Italian              | Italiano              | name_it        |\n| Japanese             | 日本語                 | name_ja        |\n| Korean               | 한국어                  | name_ko        |\n| Lithuanian           | Lietuvių              | name_lt        |\n| Latvian              | Latviski              | name_lv        |\n| Dutch                | Nederlands            | name_nl        |\n| Norwegian            | Norsk                 | name_no        |\n| Polish               | Polski                | name_pl        |\n| Portuguese (Brazil)  | Português (Brazil)    | name_pt_BR     |\n| Portuguese           | Português             | name_pt        |\n| Romanian             | Română                | name_ro        |\n| Russian              | Русский               | name_ru        |\n| Slovenian            | Slovenščina           | name_sl        |\n| Slovak               | Slovenčina            | name_sk        |\n| Serbian              | Српски (Srpski)       | name_sr        |\n| Swedish              | Svenska               | name_sv        |\n| Thai                 | ไทย                   | name_th        |\n| Turkish              | Türkçe                | name_tr        |\n| English (UK)         | English (UK)          | name_uk        |\n| Vietnamese           | Tiếng Việt            | name_vi        |\n| Chinese              | 简体中文                | name_zh        |\n\n## Data processing and asynchronicity\n\nAll inbound API resources work in the same way: they consist of synchronous and asynchronous parts.\n\n* Authentication, data validation, and persisting incoming data are done synchronously and immediately when the client sends the data.\n* The client receives a response with a 200 HTTP status code if RELEX is able to accept the request successfully and process it further.\n* If any part of the synchronous part fails, a non-2xx status code is returned. A failure indicates that RELEX has not received the data successfully, and it can not be processed further. Consequently, *the client must send the data again*.\n* After the synchronous operation, the data processing moves to an asynchronous stage. All subsequent actions are done asynchronously in the RELEX Platform outside the request-reply context.\n\nThe Data API also includes a feature called Error  API that the client can use to check for errors. For more information, see the asynchronous section.\n\n## Payload compression\n\nThe RELEX Data API does not support payload compression. Requests must omit the **Content-Encoding** header or define it as **none**.\n\n## Data validation\n\nThe RELEX Data API uses all-or-nothing semantics. For a given payload, either all records are accepted or none are. In other words, one invalid record in an otherwise valid set makes the whole set invalid.\n\nThe invalid record must be fixed or removed, and the payload sent again to allow the valid records to be processed.\n\nOn the other hand, the downstream applications handle records individually. This means that once the Data API has accepted the records, the later parts of the processing behave differently with invalid records. \n\nProblematic records are put aside and logged (see [Event API](#section/API-Specification/Errors-from-asynchronous-processing)), and processing continues from the next record.\n\n## Custom fields and resources\n\nThe RELEX Data API supports bespoke data models. To facilitate receiving custom data via standard API, the API provides bespoke resources for custom fields and resources.\n\nThe customer-specific API document includes all the resources in full, containing both standard and custom fields and resources, and their schemas.\n\n### Custom resources\n\nCustom resources follow the same concepts and patterns as standard resources, including the following patterns:\n\n* HTTP verbs: verb to denote the action type\n* Naming: human-readable resource names, plural, lowercase, separated by an underscore\n* Return codes: 2xx for success, 4xx and 5xx for failures\n\nCustom resources are added to a dedicated namespace. This is done to prevent a naming collision when new resources are added to the standard RELEX Data API interface. The namespace for custom resources is `custom`. This makes the resource path look like`/data/custom/resource`.\n\n### Custom fields\n\nSimilarly to custom resources, customer-specific fields can also be added to standard REST interfaces.\n\nCustom fields follow the same concepts as standard fields:\n\n* Naming: human-readable field names, plural, lowercase, separated by an underscore\n\nAs with resources, custom fields are also namespaced. The namespacing is done by prefixing each custom field name. The prefix is `custom_`. The resource remains otherwise the same, and all existing resources are not affected.  \n\nAs an example, when a *color* field is added to the `products` resource, the corresponding attribute in the JSON payload is named `custom_colour` and is available at the `/data/master/products` resource.\n\nYou can also remove *optional* fields from the standard resources, but there is rarely a need for that because they can be freely omitted from the request payload.\n\nIt is **not** possible to add arbitrary fields to the resources. Each field, standard and custom, must be declared in the resource schema.\n\n> ℹ️ **Custom resources do not use field prefixes**\n>\n> The fields in **custom resources** do not need to have the prefix since they are already under a distinct namespace. Thus, the fields in custom resources have no special naming requirements.\n\n## API version\n\nTo support the managed evolution of the Data API, we version its public interfaces. We have one version number that communicates all the changes to the API. This is simply called the *API version*.\n\nUnder the hood, the API version is a combination of the following:\n\n* **Core** version comprising of API semantics and usage patterns, such as authorization, payload formats, and details of requests and responses. This versioning is referred to as the *Core version* in this document.\n* **Data model version** comprising of the standard interfaces, payload schemas, and customization to existing or new resources requested by the customer. This versioning is referred to as the *data model version* in this document.\n\nThe API version is an abstraction over the two separate version concepts. For an API client, it is enough just to follow the API version.\n\n### Semantic versioning\n\nAll our version identifiers follow [semantic versioning](https://semver.org/spec/v2.0.0.html) principles. Each change to the semantics of the API increments one of the three parts of the API version number: MAJOR, MINOR, or PATCH.\n\nThe following changes guarantee an increment in the API version number:\n\n* **MAJOR** version when you make incompatible API changes,\n* **MINOR** version when you add functionality in a backward-compatible manner, and\n* **PATCH** version when you make backward-compatible bug fixes.\n\nAdditional labels for pre-release and build metadata can be used as extensions to the MAJOR.MINOR.PATCH format. For instance, `4.2.2-beta` is an allowed version specifier.\n\nThe versioning policy guarantees that only a MAJOR version upgrade can require the client to make changes.\n\nOne environment can host only one version at a time: it is not possible to have more than one version of the API running simultaneously in, for example, a *production* environment.\n\nHowever, different environments may run different versions concurrently. For example, a *user-acceptance-test* version can have a more recent version running than the *production* API.\n\n#### Version compatibility and deprecation\n\nRELEX strives to the utmost to maintain API compatibility between versions by introducing changes in a non-breaking manner whenever possible.\n\nWhen the API evolves, new features are typically added as additional resources, new fields, or new features. We avoid removing or changing existing functionality in a breaking way unless there is a very compelling reason, such as a security improvement.\n\nWith this approach, the API remains compatible even in the case of new or improved features, and the API clients can mostly remain the same. The clients may simply ignore the elements that are introduced without any adverse consequences. Only when a client explicitly takes a new feature into use, must it be adapted.\n\nIn the rare event of a breaking change, a new MAJOR core version is introduced. In that case, the feature is put behind a [feature flag](https://en.wikipedia.org/wiki/Feature_toggle). The flag by default is set to follow the existing behavior.\n\nThe customer has three (3) months to adapt to the upcoming version change before the feature flag is automatically made to follow the new behavior. Upgrade instructions are provided.\n\nThere are two exceptions to this rule:\n**A critical security-related issue is fixed immediately.** If we discover a critical security issue in the API, we do whatever is necessary to mitigate the issue as soon as possible. The fix may include disabling the vulnerable functionality until a proper solution is available. In that case, the clients need to adapt to the changes quickly.\n**Changes to customer data models** are visible immediately and are not behind feature flags.\n\n### Core versioning\n\nThe core version is derived from the changes in the system behavior, features, or other non-customer-specific changes.\n\nChanges to the core version can be; for example: \n* Introducing a new metadata resource to the API,\n* Changing the authentication pattern, or \n* Adding a new common field to a response payload.\n\nThe core version is *not* affected by changes to the data model or internal changes that do not affect the functional behavior of the system, such as updates to internal dependencies or performance improvements.\n\n### Data model versioning\n\nData API supports customer-specific bespoke fields and resources, and, commonly, customers use this powerful feature to tailor the API to their needs.\n\nDuring the project phase, it is customary that the APIs evolve rapidly. The changes may be small but breaking; for instance, changing a field data type. Or the change can be big but non-breaking, such as adding two new resources to the data model. Because the pace and nature of these changes are unrelated to API behavioral changes, the data model and the **core** version are versioned separately.\n\n### API version number\n\nThe exact version for the API combines both the *core version* and *the data model version*. It is formed by summing each semantic version number. For instance, *core* version `1.2.3` and *data model* version `4.3.2` creates an *API version* `5.5.5`. Possible suffixes are concatenated.\nAll version numbers can be queried through the API using a corresponding resource.\n\n## Resources, verbs, and URLs\n\nUnder REST principles, a URL identifies a resource. The following URL design patterns are considered REST best practices, which the RELEX Data API also follows.\n\n* URLs should include nouns, not verbs\n* Use plural nouns for consistency (no singular nouns)\n* Use HTTP methods (HTTP/1.1) to operate on the resources\n\nFor consistency, we have also defined the following practices for resource URIs:\n\n* written in lower-case letters\n* spaces are replaced with dashes (`-`)\n* resources must reside in pre-defined namespaces\n\nThe URL for the API is `PROTOCOL://ENV-GEOGRAPHY.rest.HOST/CUSTOMER`, which consists of the following parts:\n\n* `PROTOCOL` always HTTPS\n* `ENV` denoting the environment, for example, `prod`\n* `GEOGRAPHY` denoting the geography or region, for example, `us`\n* `HOST` denoting the hostname for the service, always `relexsolutions.com`\n* CUSTOMER denoting the name of the customer, for example, `bigretailer`\n\nThe API base URL, therefore, could be; for example:\n\n* uat: `uat-eu.rest.relexsolutions.com`\n* prod: `eu.rest.relexsolutions.com`\n\n### Resource namespaces\n\nThe RELEX Data API exposes the following top-level resource namespaces:\n\n* *meta*: metadata resources for business data-related aspects, such as version information\n* *data*: data namespace for business data\n  * *master*: master data resources\n  * *custom*: custom customer-specific resources\n  * *transactions*: transaction data resources\n\n### Data operations and HTTP verbs\n\nThis section describes how data operations (List, Upsert, and Delete) are mapped to HTTP verbs.\n\n| Operations      | HTTP Mapping | Request Body                             | Response Body                     |\n|-----------------|--------------|------------------------------------------|-----------------------------------|\n| List            | GET          | N/A                                      | List of records                   |\n| Delete          | DELETE       | List of records to be deleted            | Operation success or error status |\n| Upsert          | POST         | List of records to be created or updated | Operation success or error status |\n\nThe RELEX Data API deviates slightly from the traditional REST approach by commonly treating the data as collections of records instead of singular records. In practice, the API accepts and returns multiple records in one request. The other notable deviation is the usage of POST for both creating new records and updating existing records.\n\nAs RELEX operates with big datasets, the number of records sent and received through the API can be fairly large. Encoding multiple records in one request increases the API throughput as it dramatically reduces the number of individual requests that clients need to make.\n\nThis pattern applies to most of the resources regardless of the used verb. A client may create several records in a single request using the POST verb, or delete one or more records using the DELETE verb.\n\nAn important concept closely related to HTTP verbs is *idempotency*. An idempotent method means that the result of a successfully performed request is independent of the number of times the request is executed. Non-idempotent is the opposite: It means that the result may change if the request is performed more than once, even if the data remains the same.\n\n#### HTTP POST for data resources\n\nHTTP POST is used for sending records to the API in a maximum of one (1) megabyte-sized chunks per single request. A single POST request may contain one or more records that are ingested into RELEX systems.\n\nData API POST interfaces are based on the colloquial *upsert* model: new records are created for the payload items that have no matching counterparts in the RELEX database. Records that have matching database records are updated. A single request may simultaneously create new records and update existing records.\n\n**POST requests to data resources are idempotent.** Resending the same payload is safe and produces the same result. In practice, this means that if you are uncertain whether a request was received, for example due to a network failure before the response arrived, you can resend the same request without risk of creating duplicate records.\n\n##### Suggestion for data processing\n\nWhen sending data using RELEX Data API we recommend that the customer provide a `batch_id` along with each request. It is useful for the customer and RELEX to correlate processing output artifacts such as logs to the request payload.\n\nTogether within the `batch_id` we recommend sending a `timestamp` within each request. This is used internally for logging, and telemetry purposes.\n\nThese attributes are submitted in the request body `meta` section. Both items are optional but *highly recommended* to guarantee efficient operation.\n\n* A `batch_id` is a customer-specified identifier for the logical batch that is being sent. The format is [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier). Each logically separate request must have a different batch_id. Retries of the same request must use the same batch_id.\n* A `timestamp` is a value RELEX uses internally. The format of the value must be a monotonically increasing integer. If the data is sent from multiple different sources to a single resource, the clients must ensure that the different systems use the same source for the timestamp value.\n\n#### HTTP DELETE for data resources\n\nHTTP DELETE is used for deleting records in RELEX. A DELETE request may delete one or more records at a time.\n\nDELETE request is idempotent. This practice means that the first request deletes the specified rows, and subsequent retries are ignored.\n\nDeleting records is possible from master data tables. The full list of resources supporting the DELETE method can be seen in the resources section of this document.\n\n#### HTTP GET for data resources\n\nHTTP GET is used for fetching records from RELEX. A GET response contains zero or more records stored in RELEX databases.\n\nGET request is idempotent and causes no side effects.\n\n## Quotas and limits\n\nThe RELEX Data API imposes limits on incoming web requests to ensure performance, reliability, and efficiency. The API sets the following limits:\n\n* The maximum size of any POST request is 1 MB\n* The rate limit of requests per second is 5 (subject to discussion)\n\nIn case the limits are exceeded, a corresponding HTTP status code is returned with an error message detailing the issue.\n\n> ⚠️ **Exceeding payload sizes**\n>\n> In the event that the payload size exceeds 1 MB, the data needs to be split into smaller chunks and sent in multiple independent requests. Each chunk is then processed separately by RELEX.\n>\n> ℹ️  API limits are subject to change and appropriate values are determined during the implementation project.\n\nThe RELEX Data API imposes no limits on return payloads. The payload size can be arbitrarily large.\n\n### Exceeding limits\n\nIn the event of exceeding the rate-limit and receiving an HTTP status code 429, the error payload is the following:\n\n```json\n    {\n    \"type\": \"https://example.com/probs/rate-limit-exceeded\",\n    \"title\": \"You have exceeded rate limit\",\n    \"status\": 429,\n    \"detail\": \"Your rate limit has been exceeded. Please retry later.\"\n    }\n```\n\nIn the event of exceeding the request payload size-limit and receiving an HTTP status code 413, the error payload is the following:\n\n```json\n    {\n    \"type\": \"https://example.com/probs/size-limit-exceeded\",\n    \"title\": \"Payload Too Large\",\n    \"status\": 413,\n    \"detail\": \"Payload was larger than 1mb\"\n    }\n```\n\n## Error responses\n\nThe RELEX Data API uses regular HTTP response codes to indicate the various failures an API request can return. Codes in the 4xx range indicate an error on the client side, for example, the resource name was incorrect. Codes in the 5xx range indicate an error within RELEX services.\n\nTo convey details about errors to clients in JSON responses, the RELEX Data API uses the [RFC 7807](https://tools.ietf.org/html/rfc7807) standard.\n\n| Error code                | Description                                                                                            |\n|---------------------------|--------------------------------------------------------------------------------------------------------|\n| 400 Bad Request           | The request was unacceptable, for example, due to a missing parameter                                  |\n| 401 Unauthorized          | The client is unauthorized. The bearer token provided might be invalid, expired, or revoked            |\n| 403 Forbidden             | The client is forbidden. This might be due to connectivity restriction                                 |\n| 404 Page Not Found        | Resource was not found                                                                                 |\n| 413 Content Too Large     | Size limits exceeded. See more in the rate limits section                                              |\n| 429 Too many requests     | Rate limits exceeded. See more in the rate limits section                                              |\n| 500 Internal server error | Generic server error indicating an unexpected problem. A client may retry                              |\n| 503 Service unavailable   | The service is temporarily unavailable, for example, due to a system upgrade. A client may retry later |\n\n## Errors from asynchronous processing\n\nThe RELEX Data API provides a resource that can be used to query errors emitted during the asynchronous processing; that is, after the data has been successfully ingested by the RELEX Data API.\n\nThe nature of asynchronous processing is such that errors can appear at any moment until the data processing finishes. For this reason, the response to the request might be different over time. Hence, the resource needs to be queried periodically to get the full result.\n\n### Fetching errors\n\nThere are two mutually exclusive ways of fetching errors: either by request or by time.\n\nFor fetching errors for a particular request, the client must supply a `request_id`.  The `request_id` parameter is an identifier that is returned in the response for all POST and DELETE requests. The identifier can then be used later to track the ingestion errors for that particular request. Think of it as a handle for an asynchronous background processing job.\n\nFor fetching errors by time, a `start_timestamp` (inclusive) and `end_timestamp` (exclusive) pair must be supplied. Timestamps can be used for fetching all ingestion errors that occurred during the specified time window.\n\nFetching by request and timestamp are mutually exclusive. They cannot be used simultaneously.\n\n### Pagination of error responses\n\nTo limit the potential response size, the number of errors returned in one response is capped.\n\nThe following optional query parameters must be used when the number of errors exceeds the amount one response can return.\n\n* `page` is used to define the desired set of all available sets when the amount of errors in the response is more than the limit.\n* `per_page` is used to define the maximum amount of items one response can hold. There is an upper maximum (10000) for the parameter that cannot be exceeded.\n\nTo be able to traverse between pages more easily, the RELEX Data API also provides links to the subsequent pages. Each error response contains the following structure:\n\n```json\n\"_links\": {\n    \"self\": {\n        \"href\": \"/errors?request_id=2eb6aceb-731c-45f9-8427-41d6087c0983\"\n    },\n    \"next\": {\n        \"href\": \"/errors?request_id=2eb6aceb-731c-45f9-8427-41d6087c0983&page=2\"\n    }\n},\n```\n\nThe `href` attribute under the `_links.next` attribute in the response body contains a relative URL for the next batch. When the `next` attribute is missing, there are no more batches available *at present*. However, asynchronicity means that there can be new items available in the next moment.\n\nIf there are no errors that meet the given query, the response is `200 OK` with empty `data` array.\n\n## Disaster recovery\nDisaster recovery (DR) is an organization’s ability to restore access and functionality to IT infrastructure after a disastrous event. These can range from natural disasters to human errors.\n\nRELEX Data API uses active/hot-standby approach with a DNS-based traffic load balancer.\n\n#### Hot-standby approach \nOur approach involves two environments located in different geographical regions. Traffic is directed to a primary environment while the other is reserved for disaster recovery purposes. It utilises an active/hot-standby configuration, meaning that only one region is actively used to direct user traffic, while the other region remains ready but mostly inactive.\n\n#### DNS-based traffic load balancer\nDuring normal operations the load balancer routes the incoming traffic to the primary environment. In the event of a disaster the load balancer switches to the hot-standby environment. \n\n#### Client considerations\nIn order to have a fast and optimal recovery from a disaster, it is crucial for clients to respect the ttl (time-to-live) sent by the DNS server. If the client caches the records too long, it can generate a long delay in the detection of the failover initiated by the load balancer. It is recommended to read through documentation for the programming language and the libraries that are used to access RELEX Data API to ensure expected behaviour.\n\nThe failover to secondary environment can take up to two minutes to avoid any unnecessary region switch-overs. If the disaster is generating failing requests (non-2xx status code returned), the clients must be ready to retry the failing requests as mentioned in `Data processing and asynchronicity section`\n\n#### Disaster Recovery Testing\nRELEX reserves the right to perform basic disaster recovery testing when necessary (approximately once a year). This is done to ensure that the best possible service is provided even during a disaster. These operations are designed not generate any traffic outage for clients, but there is a small risk due to the nature of the tests. Customers are always 

# --- truncated at 32 KB (188 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/relex/refs/heads/main/openapi/relex-transactions-api-openapi.yml