> ## Documentation Index > Fetch the complete documentation index at: https://docs.bespot.com/llms.txt > Use this file to discover all available pages before exploring further. # Info exchange flow > Data exchange flow between your systems and Bespot Gatekeeper APIs. # Key Components In this section, you’ll find a high-level overview of the components involved in integrating with Bespot Gatekeeper and how they exchange information. The following diagram offers a visual representation, and each component is detailed afterwards. By reviewing this overview first, you’ll gain the necessary context before integrating Bespot’s SDKs and services. Information Exchange Flow Diagram ## Bespot Auth Server The *Auth Server* issues access tokens based on the *Client Credentials Flow*, as defined in OAuth 2.0 (RFC 6749, Section 4.4). It is used in the server-to-server verification flow, granting the Client Server access to the API Server’s endpoints, specifically the `/api/s2s/verify` endpoint. The access tokens are in the form of JWTs (JSON Web Tokens) following the RFC 7519. ## Bespot API Server The *API Server* exposes all available endpoints. Any entity that needs to consume these endpoints must be first authorized. The access token (JWT), previously acquired from the *Auth Server*, must be provided in the Authorization HTTP header with the `“Bearer ”` prefix for the resource to be accessible. Otherwise, a `401 Unauthorized` HTTP error is returned. ## Client Server This is the customer’s *Client Server*. It receives verification requests from the customer’s frontend applications (Web, iOS, Android). These requests include the Action and Ticket information, which is then used as the body payload for the `/api/s2s/verify` HTTP endpoint of the API Server. Following successful verification of the Policy Action based on the *Ticket* information by the API Server, the *Client Server* informs the frontend applications that the verification is completed, allowing the transaction to proceed. The Ticket is an encrypted string that can only be decrypted by the API Server and contains all information regarding the Detection Results, the *Policy Action*, and the timestamp information that the frontend applications initially received. ## Bespot Web SDK The Web SDK incorporates functionality for performing detections on the *Web Browser*, communicating with Bespot’s *API Server*, and receiving the *Policy Action*. The Web SDK is the library to be used, as a dependency, in the customer’s application to provide the *Policy Action*. ## Bespot iOS SDK The *iOS SDK* incorporates functionality for performing detections in iOS devices, communicating with Bespot’s *API Server* and receiving the *Policy Action*. The iOS SDK is the library to be used, as a dependency, in the customer’s iOS mobile application to provide the *Policy Action*. ## Bespot Android SDK The *Android SDK* incorporates functionality for running checks in Android devices, communicating with Bespot’s *API Server* and receiving the *Policy Action*. The Android SDK is the library to be used, as a dependency, in the customer’s Android mobile application to provide the *Policy Action*. ## Client Web App This is the customer's web application where Bespot’s *Web SDK* is used as a dependency and provides the *Policy Action*. ## Client iOS App This is the customer's iOS application where Bespot’s *iOS SDK* is used as a dependency and provides the *Policy Action*. ## Client Android App This is the customer's Android application where Bespot’s *Android SDK* is used as a dependency and provides the *Policy Action*.