Hubert / Updating technical documentation content

docs/_client-libraries/_category_.json

@@ -1,5 +1,5 @@
 {
-  "label": "Client Libraries",
+  "label": "Client libraries",
   "position": 5,
   "link": {
     "type": "generated-index",

docs/_client-libraries/flutter/project-setup/index.md

@@ -1,5 +1,5 @@
 ---
-title: Project Setup
+title: Project setup
 sidebar_label: Setup
 sidebar_position: 0
 ---

docs/_client-libraries/typescript/project-setup/index.md

@@ -1,5 +1,5 @@
 ---
-title: Project Setup
+title: Project setup
 sidebar_label: Setup
 sidebar_position: 0
 ---

docs/_terminology/trading/landing-company-calls/landing-company/index.md

@@ -23,4 +23,4 @@ The company has a number of licensed subsidiaries in various jurisdictions, whic
 
 This call will return the appropriate Landing Company for clients of a given country.
 
-The landing company may differ for Gaming contracts (Synthetic Indices) and Financial contracts (Forex, Stock Indices, Commodities).
+The landing company may differ for Synthetic Indices and Financial contracts (Forex, Stock Indices, Commodities).

docs/code-examples/javascript/_category_.json

@@ -1,8 +1,8 @@
 {
-  "label": "Javascript Examples",
+  "label": "JavaScript Examples",
   "position": 1,
   "link": {
     "type": "generated-index",
-    "description": "Javascript code examples"
+    "description": "JavaScript code examples"
   }
 }

docs/core-concepts/_category_.json

@@ -1,8 +1,8 @@
 {
-  "label": "Core Concepts",
+  "label": "Core concepts",
   "position": 2,
   "link": {
     "type": "generated-index",
-    "description": "Learn core concepts of Deriv API websocket server and it's features"
+    "description": "Learn core concepts of the Deriv API WebSocket server and its features"
   }
 }

docs/core-concepts/api-calls-anatomy/index.md

@@ -1,17 +1,21 @@
 ---
-title: API Calls Anatomy
-hide_title: true
+title: API calls' anatomy
+hide_title: false
 draft: false
-sidebar_label: API Calls anatomy
+sidebar_label: API calls' anatomy
 sidebar_position: 1
 tags:
   - concept
+  - calls
+  - anatomy
 keywords:
   - trading
   - concept
-description: Deriv API calls Anatomy
+  - calls
+  - anatomy
+description: Deriv API calls' anatomy
 ---
-## Subscribe and Send
+## Subscribe and send
 
 All API calls have a send functionality for making a request and receiving a response. Certain API calls also offer a subscribe functionality allowing for updates to be sent to your application when new information becomes available.
 
@@ -23,42 +27,42 @@ Some of these API calls automatically subscribe (e.g. [ticks](https://api.deriv.
 
 For example, you can call [Tick History](https://api.deriv.com/api-explorer#ticks_history) to receive tick history data. But when you add the `subscribe` option to this call, you will receive the tick history data you requested in the first response, and you will continue to receive a new response every time there is a new tick published by the server for the given symbol.
 
-In the message stream from `subscribe` there is a field called `subscription`, this is the `Stream ID`. with this ID you can identify the message stream in your logic and stop the stream with `Forget` and `Forget All` API calls.
+In the message stream from `subscribe`, there is a field called `subscription`. This is the `Stream ID`. With this ID, you can identify the message stream in your logic and stop the stream with `Forget` and `Forget All` API calls.
 
 The data provided by API calls with the `subscribe` functionality can be used as a data source for other API calls and features.
 
 ### Send
 
-If you call the API with the `send` functionality, then the server will only send back the requested data one time. In order to get updated data you have to send the API call again. Usually, this method is used when you get other API call responses or UI events such as `Click`, `Scroll` and more.
+If you call the API with the `send` functionality, then the server will only send back the requested data one time. In order to get updated data, you have to send the API call again. Usually, this method is used when you get other API call responses or UI events such as `Click`, `Scroll`, and more.
 
 ### Forget
 
-If you want to stop the message Stream created by `subscribe`, you will have to call the `Forget` API call with the correct `Stream ID`. Otherwise, you can use the `Forget All` API call to stop streams by their `Method name`.
+If you want to stop the message stream created by `subscribe`, you will have to call the `Forget` API call with the correct `Stream ID`. Otherwise, you can use the `Forget All` API call to stop streams by their `Method name`.
 
 :::caution
-For more information on the `Forget` API call, you can have a look at [Forget](https://api.deriv.com/api-explorer#forget) and [Forget All](https://api.deriv.com/api-explorer#forget_all) in the API explorer.
+For more information on the `Forget` API call, have a look at [Forget](https://api.deriv.com/api-explorer#forget) and [Forget All](https://api.deriv.com/api-explorer#forget_all) in the API explorer.
 :::
 
 
-## Request Data
+## Request data
 
-In order to make it easier for you to handle the `request` and `response` flow of your websocket connection, every deriv websocket API calls has a general structure. you can use it for caching, validation, request and response synchronization are some of the things you can use it for.
+To make it easier for you to handle the request and response flow of your WebSocket connection, each Deriv WebSocket API call follows a standardised structure. You can use it for caching, validation, request, and response synchronisation.
 
-#### API Call Method Name
+#### API call method name
 
 Every `request` in the WebSocket API includes a `method name` field that serves as a unique identifier for the request. In most cases, this  `method name` will get a numerical value of `1`. However, there are some cases where the identifier property may have a string value.
 
 :::caution
-API Call Method Name is always required. this field determines the data you'll get from our websocket server.
+API Call Method Name is always required. this field determines the data you'll get from our WebSocket server.
 :::
 
-### Required Fields
+### Required fields
 
-Every request data has several required fields which you must provide them and they may contain optional fields as well, let's explore this with an example on `Residence List`:
+Each request data has mandatory fields that you must provide, and it may also include optional fields. Let's explore this with an example from `Residence List`.
 
-`Residence List` Call returns a list of countries and 2-letter country codes, suitable for populating the account opening form.
+A `Residence List` call returns a list of countries and 2-letter country codes, suitable for populating the account opening form.
 
-Request data for this call is like so:
+The request data for this call is as below:
 
 ```ts
 {
@@ -68,27 +72,27 @@ Request data for this call is like so:
 }
 ```
 
-The `residence_list` field is the `method name` for the call and is required. There may be other required fields which are related to this type of the request you want to send. if you want to know more about `Residence List` and other API calls please check them out in the [API Explorer](https://api.deriv.com/api-explorer#residence_list).
+The `residence_list` field is the `method name` for the call and is required. There may be other required fields related to this type of the request you want to send. To know more about `Residence List` and other API calls, please check them out in [API Explorer](https://api.deriv.com/api-explorer#residence_list).
 
-### Optional Fields
+### Optional fields
 
-Every Call has several `Optional` fields as well, `passthrough` and `req_id` are always part of the request data but you can choose to opt-out and not use them.
+Every call has several `Optional` fields as well. `Passthrough` and `req_id` are always part of the request data but you can choose to opt out and not use them.
 
-#### `passthrough` Field
+#### The `passthrough` field
 
-Whatever you pass to this field will be returned back to you inside a `response` object, this can be helpful when you need to simulate a stateful flow for your `requests` and `responses`.
+Whatever you pass to this field will be returned back to you inside a `response` object. This can be helpful when you need to simulate a stateful flow for your `requests` and `responses`.
 
-#### `req_id` Field
+#### The `req_id` field
 
-You may need to `tag` your requests and pass them through our `websocket` calls. you can do it by passing a `number` to this field. it can be helpful when you need to map `requests` to `responses`.
+You may need to `tag` your requests and pass them through our `WebSocket` calls. You can do so by passing a `number` to this field. it can be helpful when you need to map `requests` to `responses`.
 
 :::caution
-There may be other optional fields for a request which are only related to that API call, please check our [API Explorer](https://api.deriv.com/api-explorer) to get familiar with them.
+To learn about additional optional fields specific to each API call, please refer to our [API Explorer](https://api.deriv.com/api-explorer).
 :::
 
-## Response Data
+## Response data
 
-When you get the response for the call, there will be a `Field` with the same name as the `method name`. and it contains the actual data.
+When you get the response for the call, there will be a `Field` with the same name as the `method name`, which contains the actual data.
 
 The response for the `Residence List` call:
 
@@ -159,15 +163,15 @@ The response for the `Residence List` call:
 };
 ```
 
-Here the `residence_list` is the `method name` and it contains the actual data you requested. rest of the array is removed here for brevity sake, you can check the actual response [here](https://api.deriv.com/api-explorer#residence_list).
+Here the `residence_list` is the `method name`, and it contains the actual data you requested. To keep it short, we haven't included the rest of the array. You can check the actual response [here](https://api.deriv.com/api-explorer#residence_list).
 
-#### The `echo_req` Field
+#### The `echo_req` field
 
 This `Field` contains the exact `Request Data` you sent to the server.
 
-#### The `msg_type` Field
+#### The `msg_type` field
 
-This `Field` helps you determine which `message` data you're getting on the message event of the websocket connection. For example, your `onmessage` event handler for your websocket connection in `Javascript` would be:
+This `Field` helps you determine which `message` data you're getting on the message event of the WebSocket connection. For example, your `onmessage` event handler for your WebSocket connection in `JavaScript` would be:
 
 ```js
 socket.onmessage = (event) => {
@@ -186,7 +190,7 @@ socket.onmessage = (event) => {
 }
 ```
 
-#### The `req_id` Field
+#### The `req_id` field
 
 This is the `Optional` passed to the `Request Data`, you can use it for `validation`, `synchronization`, `caching`, etc.
 

docs/core-concepts/authorization-authentication/index.md

@@ -1,75 +1,74 @@
 ---
-title: Authorization and Authentication
+title: Authorisation and authentication
 hide_title: false
 draft: false
-sidebar_label: Authorization and Authentication
+sidebar_label: Authorisation and authentication
 sidebar_position: 2
 tags:
   - authentication
-  - authorization
+  - authorisation
 keywords:
   - deriv-authentication
-  - deriv-authorization
-description: deriv api authentication and authorization
+  - deriv-authorisation
+description: Deriv API authorisation and authentication
 ---
-
-Without authentication and authorization you'll only get access to roughly half of our API calls and features. for example in order to buy contracts or utilize the `Copy Trading` features your users must be authenticated and authorized by our **OAuth** provider and **Websocket Server**.
+Without authorisation and authentication you'll only get access to roughly half of our API calls and features. For example, in order to buy contracts or utilise the `Copy Trading` features, your users must be authenticated and authorised by our **OAuth** provider and **WebSocket Server**.
 
 ## Before we start
 
-You have to make sure you have all the requirements mentioned bellow to continue.
+Please make sure you have all the requirements mentioned below to continue.
 
 ### Requirements
 
-1. Deriv Account
-2. Deriv API Token with the appropriate access level
-3. Deriv App ID
+1. Deriv account 
+2. Deriv API token with the appropriate access level
+3. Deriv app ID 
 
 :::note
-Please refer to [Setting up a Deriv Application](/docs/setting-up-a-deriv-application.md) for detailed instruction how to create Deriv API token and Applications
+Please refer to [Setting up a Deriv application](docs/setting-up-a-deriv-application.md) for detailed instructions how to create a Deriv API token and application.
 :::
 
-### API Token
+### API token
 
-An API token is a unique identifier of a client that requests access from a server. It's the simplest way of authorization.
+An API token is a unique identifier of a client that requests access from a server. It's the simplest way of authorisation.
 
 The access level for each API token has to match the required access level of each API call, which can be found in the [API Explorer](https://api.deriv.com/api-explorer) as well.
 
 For example, on the screenshot below, you can see that to be able to use the Account Status, a token with read access level must be used.
 
 ![](/img/acc_status_scope_api_explorer.png)
 
-Following the authorization of a Websocket connection, subsequent calls on that connection will be considered user actions.
+Following the authorisation of a WebSocket connection, subsequent calls on that connection will be considered user actions.
 
 Please bear in mind that the API token can be used with any app, so both your app and your clients need to keep it secure.
 
 ### OAuth2
 
-OAuth stands for Open Authorization - a protocol that allows a client access resources hosted on a server on behalf of the user without revealing the credentials.
+OAuth stands for `Open Authorisation` — a protocol that allows a client to access resources hosted on a server on behalf of the user without revealing the credentials.
 
-This type of authorization allows clients to log in to third-party apps using their Deriv accounts without creating an API token. In this case, the third-party app does not see the user's password or permanent API token, which makes it safer.
+This type of authorisation allows clients to log in to third-party apps using their Deriv accounts without creating an API token. In this case, the third-party app does not see the user's password or permanent API token, which makes it safer.
 
 The OAuth2 authentication requires more steps to set up, but it is the safest way for developers to share access to their app with their clients.
 
 For more information on OAuth2, visit [this guide](https://aaronparecki.com/oauth-2-simplified/).
 
-Here is the visual representation of how the OAuth authorization connection works:
+Here is the visual representation of how the OAuth authorisation connection works:
 
 ![OAuth flow](/img/how_oauth_works.png 'OAuth flow')
 
-## Authentication Process
+## The authentication process
 
-In order to Authenticate your user, specify the URL that will be used as the OAuth Redirect URL on the [Dashboard](/dashboard) page, **Register application** tab in the **OAuth details** fields and then Add a login button on your website or app and direct users to **`https://oauth.binary.com/oauth2/authorize?app_id=your_app_id`** where your_app_id is the ID of your app.
+In order to authenticate your user, specify the URL that will be used as the OAuth Redirect URL on the [Dashboard](/dashboard) page, **Register application** tab in the **OAuth details** fields. Then, add a login button on your website or app and direct users to **`https://oauth.binary.com/oauth2/authorize?app_id=your_app_id`** where your_app_id is the ID of your app.
 
 ![Deriv OAuth Login](/img/oauth_login.png 'Deriv OAuth Login')
 
-Once a user signs up / signs in, they will be redirected to the URL that you entered as the Redirect URL. This URL will have arguments added to it with the user's session tokens, and will look similar to this:
+Once a user signs up/logs in, they will be redirected to the URL that you entered as the Redirect URL. This URL will have arguments added to it with the user's session tokens, and will look similar to this:
 
 `https://[YOUR_WEBSITE_URL]/redirect/?acct1=cr799393& token1=a1-f7pnteezo4jzhpxclctizt27hyeot&cur1=usd& acct2=vrtc1859315& token2=a1clwe3vfuuus5kraceykdsoqm4snfq& cur2=usd`
 
-## Authorization Process
+## The authorisation process
 
-The query params in the redirect URL are the user's accounts and their related session tokens. you can map the query params to an array like so:
+The query parameters in the redirect URL are the user's accounts and their related session tokens. You can map the query parameters to an array using the following approach:
 
 ```js
 const user_accounts = [
@@ -85,17 +84,14 @@ const user_accounts = [
   },
 ];
 ```
-
-To authorize the user, based on the user's **Selected** account, call the [authorize](https://api.deriv.com/api-explorer#authorize) API call with the user's **Selected** account **Session Token**:
-
+To authorise the user based on the user's **selected** account, call the [authorize](https://api.deriv.com/api-explorer#authorize)  API call with the user's **selected** account **session token**:
 ```js
 {
   "authorize": "a1-f7pnteezo4jzhpxclctizt27hyeot"
 }
 ```
 
-The response for the `authorize` call would be an object like so:
-
+The response for the `authorize` call would be an object as below:
 ```js
 {
     "account_list": [
@@ -149,5 +145,4 @@ The response for the `authorize` call would be an object like so:
     "user_id": 12345678
   }
 ```
-
-Now user is authorized and you use Deriv API calls on behalf of the account.
+Now, the user is authorised, and you can use Deriv API calls on behalf of the account.