# Service API Fail Safe Features

## Overview

This section is an extension of the information provided in the API reference documentation and describes the fail-safe setup of the API end-points of Fredhopper Services and provides a guideline for the integration of these APIs.

## Services API <a href="#servicesapifailsafefeatures-servicesapi" id="servicesapifailsafefeatures-servicesapi"></a>

The Services API accepts requests to supply or retrieve data and trigger the data processing. Although we support both the FTP and REST protocols to interface with the Services API, **we strongly recommend using REST**.

The diagram below depicts the overview of the infrastructure setup and indicates the fail-safe components:

<figure><img src="/files/IFxsbG9KDPpnyBGwgQf1" alt=""><figcaption></figcaption></figure>

## Infrastructural Components <a href="#servicesapifailsafefeatures-infrastructuralcomponents" id="servicesapifailsafefeatures-infrastructuralcomponents"></a>

### Front-end <a href="#servicesapifailsafefeatures-front-end" id="servicesapifailsafefeatures-front-end"></a>

By front-end we mean the complete set of components in the web application on the customer's side involved with the integration of the Services API. One could think of the application back end servers and the underlying infrastructure, proxies and other network appliances etc.

### Internet <a href="#servicesapifailsafefeatures-internet" id="servicesapifailsafefeatures-internet"></a>

The front-end web application connects to the Services API endpoint via the Internet.

### DNS Authority <a href="#servicesapifailsafefeatures-dnsauthority" id="servicesapifailsafefeatures-dnsauthority"></a>

We register the DNS names for the API end-points with a 3rd party DNS service provider. To ensure high availability, each DNS record for the Services API endpoint contains a set of public IP addresses of our Data API servers and adheres to the [Round-Robin DNS](http://en.wikipedia.org/wiki/Round-robin_DNS) principle. In short, this means that every time the DNS name gets resolved into an IP address that is different from the previous time. In order to minimise the chance of issues related to DNS caching, we set the [TTL](http://en.wikipedia.org/wiki/Time_to_live#DNS_records) to 30 seconds. Your Technical Consultant can provide you with a full list of the IP addresses in our range so that you can ensure that these are whitelisted on your-side, if this is required.

{% hint style="danger" %}
The hostname alone does not identify any specific service instance. Instead, the service instance is referenced in the path, e.g. <https://my.\\><region>.fredhopperservices.com/\<service>:\<instance>
{% endhint %}

### Data API Node <a href="#servicesapifailsafefeatures-dataapinode" id="servicesapifailsafefeatures-dataapinode"></a>

Each of the Data API servers (or nodes) fulfil the following functions:

* **Authentication** Each request gets authenticated based on the supplied account credentials
* **Processing** Once authorised, the request gets processed. Depending on the type of the request, it might be either handled directly by the Data API node, or by other internal components.
* **Storage** The data supplied via the Services API gets stored for a short period of time alongside the information regarding the trigger processing etc.

All Data API nodes have identical configuration and functionality, they also share the same underlying storage and processing clusters.

### Mechanisms <a href="#servicesapifailsafefeatures-mechanisms" id="servicesapifailsafefeatures-mechanisms"></a>

#### Data flow (Full load, automatic id)

1. The front-end prepares the data export, compresses it, calculates the md5 checksum and sends it to the Services API endpoint.
2. The Services API endpoint DNS name gets resolved. The DNS authority answers with the external IP of one of the Data API nodes.
3. The front-end sends the data to the IP address, indicating the service instance in the path and supplying the account credentials.
4. The Data API node processes the request, verifies and stores the data and assigns it a data ID, which it sends back as the response.

### Integration guideline <a href="#servicesapifailsafefeatures-integrationguideline" id="servicesapifailsafefeatures-integrationguideline"></a>

#### DNS resolving and caching

* Make sure the DNS record is resolved each time before a request is sent and only send 1 request to 1 IP at a time.
* Make sure the TTL advertised with the DNS record (30 seconds) is respected.

#### Implementation optimisation

* For a given service instance, send the requests sequentially, awaiting the response each time. For example, if the data uploading process is still running, sending a trigger would result in a failure.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://crownpeak.gitbook.io/product-discovery/sending-and-managing-product-data/flatfiles/custom-datafeed/services-api-fail-safe-features.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.