Updated documentation with minor changes

felixdrud · felixdrud · commit de02b7d810e5 · 2025-11-17T14:40:55.000+01:00
diff --git a/README.md b/README.md
@@ -119,7 +119,7 @@ catch (QueueITException e) { } // Gets thrown when a request is already in progr
 | eventIdOrAlias    | Yes                                      | Id of the waiting room or alias                                                                                                                                                               |
 | layoutName        | No (Waiting Room's default theme)        | Layout name to use for the waiting room. If omitted, the Waiting Room's default layout will be used                                                                                           |
 | language          | No (Waiting Room's default language)     | Language id to use for the waiting room. If omitted, the Waiting Room's default language will be used                                                                                         |
-| waitingRoomDomain | No (`{customerId}.queue-it.net`)         | Custom Waiting Room domain to use for the requests from Mobile to Queue-it. Can be a Proxy Domain, if you are running Queue-it Behind Proxy                                                   |
+| waitingRoomDomain | No (`{customerId}.queue-it.net`)         | Custom Waiting Room domain to use for the requests from Mobile to Queue-it. Can be a Proxy Domain, if you are using Bring Your Own CDN                                                        |
 | queuePathPrefix   | No (none)                                | Queue Path Prefix to use, if you are running Waiting Room on same domain as your normal website. Requires waitingRoomDomain to also be provided. If not, then this parameter will be ignored. |
 | queueListener     | Yes                                      | Listener with callback functions. Must implement the `QueueListener` interface.                                                                                                               |
 | options           | No (`QueueItEngineOptions.getDefault()`) | Allows you to configure the WebView used to show the Waiting Room. Can disable back button (default: disabled) and set a custom User Agent (default: "")                                      |
@@ -175,7 +175,7 @@ Calling any of these methods will result in executing `onSuccess` or `onFailure`
 | eventIdOrAlias                     | Yes                                  | Id of the waiting room or alias                                                                                                                                                               |
 | layoutName                         | No (Waiting Room's default theme)    | Layout name to use for the waiting room. If omitted, the Waiting Room's default layout will be used                                                                                           |
 | language                           | No (Waiting Room's default language) | Language id to use for the waiting room. If omitted, the Waiting Room's default language will be used                                                                                         |
-| waitingRoomDomain                  | No (`{customerId}.queue-it.net`)     | Custom Waiting Room domain to use for the requests from Mobile to Queue-it. Can be a Proxy Domain, if you are running Queue-it Behind Proxy                                                   |
+| waitingRoomDomain                  | No (`{customerId}.queue-it.net`)     | Custom Waiting Room domain to use for the requests from Mobile to Queue-it. Can be a Proxy Domain, if you are using Bring Your Own CDN                                                        |
 | queuePathPrefix                    | No (none)                            | Queue Path Prefix to use, if you are running Waiting Room on same domain as your normal website. Requires waitingRoomDomain to also be provided. If not, then this parameter will be ignored. |
 | queueITWaitingRoomProviderListener | Yes                                  | Listener with callback functions. Must implement the `QueueITWaitingRoomProviderListener` interface.                                                                                          |
 
@@ -191,13 +191,13 @@ QueueITWaitingRoomView queueITWaitingRoomView = new QueueITWaitingRoomView(MainA
 queueITWaitingRoomView.showQueue(_queuePassedInfo.getQueueUrl(), _queuePassedInfo.getTargetUrl());
 ```
 
-## Client-side mobile integration with Queue-it Behind Proxy (Bring your own CDN)
+## Client-side mobile integration with Bring Your Own CDN
 
 > Note: This only applies if you are using the Mobile SDK as a client-side protection only. I.e. this does not apply if you are protecting the API endpoints your Mobile app is using.
 
 > If you have server-side Queue-it protection on your API endpoints, please see section [below](#mobile-sdk-integration-with-protected-api-queue-it-connector-on-server-side).
 
-If you are running Queue-it behind your own reverse proxy the Mobile Integration can also be setup to run behind your proxy.
+If you are running Queue-it with Bring Your Own CDN, on your own reverse proxy, the Mobile Integration can also be setup to run behind your reverse proxy.
 
 To do this simply use your Proxy Domain as the `waitingRoomDomain` parameter to `QueueITEngine.run`. If you are running Queue-it Waiting Room on the same domain as your normal website, you also need to provide the `queuePathPrefix` parameter, to ensure your proxy can route the request to Queue-it origin.
 
diff --git a/documentation/protected_apis.md b/documentation/protected_apis.md
@@ -1,9 +1,11 @@
 # Using Queue-it server-side connector (KnownUser) to protect APIs, consumed by mobile app
+
 If you are using Queue-it's server-side connector (KnownUser) to protect your API, you utilize this in your mobile app, to run a hybrid setup.
 
 This greatly increases the protection and prevents visitors from bypassing the client-side Queue-it integration.
 
 The flow in this setup is the following (simplified):
+
 1. Mobile app calls API endpoints and includes the special Queue-it header
    Endpoint is protected by Queue-it connector
 2. Queue-it connector has Trigger/Condition setup to match an Integration Action/Rule, with Queue action-type
@@ -22,28 +24,30 @@ To integrate with a protected API we need to handle the validation responses tha
 All calls to protected APIs need to include the `x-queueit-ajaxpageurl` header with a non-empty value and a Queue-it accepted cookie (if present).
 The integration can be described in the following steps:
 
-1. API Request with `x-queueit-ajaxpageurl` *or* Queue-it accepted cookie is made
+1. API Request with `x-queueit-ajaxpageurl` _or_ Queue-it accepted cookie is made
 2. We get a response which may either be the API response or an intercepted response from the Queue-it connector
 3. Scenario 1, user should not be queued (response does not have the `x-queueit-redirect` header)
-    1. We store the Queue-it cookies from the response, to include in later API calls
+   1. We store the Queue-it cookies from the response, to include in later API calls
 4. Scenario 2, user should be queued
-    1. If the user should be queued we'll get a `200 Ok` response with a `x-queueit-redirect` header. We need to extract the `c`(Customer ID) and `e` (Waiting Room ID) query string parameters from the `x-queueit-redirect` header and call `QueueITEngine.run` with them, just as you would normally do with the SDK
-    2. We wait for the `onQueuePassed` callback and we store the QueueITToken passed to the callback
-    3. We can repeat the API request, this time appending the `queueittoken={QueueITToken}` query string parameter, to prevent the server-side connector from intercepting the call again
-    4. We store the Queue-it cookies from the final response, so they can be set in other API calls
+   1. If the user should be queued we'll get a `200 Ok` response with a `x-queueit-redirect` header. We need to extract the `c`(Customer ID) and `e` (Waiting Room ID) query string parameters from the `x-queueit-redirect` header and call `QueueITEngine.run` with them, just as you would normally do with the SDK
+   2. We wait for the `onQueuePassed` callback and we store the QueueITToken passed to the callback
+   3. We can repeat the API request, this time appending the `queueittoken={QueueITToken}` query string parameter, to prevent the server-side connector from intercepting the call again
+   4. We store the Queue-it cookies from the final response, so they can be set in other API calls
 
 ![API Integration Flow](https://github.com/queueit/android-webui-sdk/blob/master/documentation/App%20+%20Connector%20integration%20with%20QueueITToken.png "App Integration Flow")
 
-## Client-side and server-side mobile integration (hybrid) with Queue-it Behind Proxy (Bring your own CDN)
-> Note: This only applies if you are using the Mobile SDK as a client-side protection *and* are using server-side protection using the Queue-it KnownUser Connector.
+## Client-side and server-side mobile integration (hybrid) with Bring Your Own CDN
+
+> Note: This only applies if you are using the Mobile SDK as a client-side protection _and_ are using server-side protection using the Queue-it KnownUser Connector.
 
 > If you are only using client-side protection, using the Mobile SDK, refer to the documentation in the [main documentation](https://github.com/queueit/android-webui-sdk/blob/master/README.md)
 
-If you are running Queue-it behind your own reverse proxy the Mobile Integration can also be setup to run behind your proxy. For the hybrid setup, your KnownUser connector will also need to run in "Behind Proxy" mode. Please contract Queue-it Support, for any questions the KnownUser Connector Behind Proxy Setup.
+If you are running Queue-it with Bring Your Own CDN, on your own reverse proxy, the Mobile Integration can also be setup to run behind your reverse proxy. For the hybrid setup, your KnownUser connector will also need to run in "Bring Your Own CDN" mode. Please contract Queue-it Support, for any questions related to the KnownUser Connector setup with Bring Your Own CDN.
+
+### Setup Mobile SDK with Bring Your Own CDN, with protected API
 
-### Setup Mobile SDK with Behind Proxy, with protected API
 To do this simply use your Proxy Domain as the `waitingRoomDomain` parameter to `QueueITEngine.run`, after getting the Queue-it intercepted response back from your API.
 
 If you are running Queue-it Waiting Room on the same domain as your normal website, you also need to provide the `queuePathPrefix` parameter, to ensure your proxy can route the request to Queue-it origin.
 
-This means in ahove [Implementation](#implementation) section, point 4.1, you must also provide `waitingRoomDomain` and optionally `queuePathPrefix` to `QueueITEngine.run`, to serve the Waiting Room through your reverse proxy.
+This means in ahove [Implementation](#implementation) section, point 4.1, you must also provide `waitingRoomDomain` and optionally `queuePathPrefix` to `QueueITEngine.run`, to serve the Waiting Room through your reverse proxy.
