docs: add new integration and CLI documentation, update links and references across various sections

Author: guiwrite

docs/docs/administration-and-security/access-control/index.md

@@ -2,7 +2,7 @@
 title: Authentication
 description: Customise how your users log in to the Flagsmith dashboard
 sidebar_label: Overview
-sidebar_position: 1
+sidebar_position: 10
 ---
 
 Flagsmith supports a variety of authentication methods for logging into the dashboard:

docs/docs/administration-and-security/access-control/rbac.md

@@ -1,7 +1,7 @@
 ---
 title: Role-based access control
 sidebar_label: Role-based Access Control
-sidebar_position: 60
+sidebar_position: 1
 ---
 
 :::info
@@ -17,7 +17,7 @@ For example, RBAC allows you to achieve the following scenarios:
 
 - Only allow certain users to modify your production environments.
 - Grant a default set of permissions to all users that join your Flagsmith organisation.
-- Lock down an [Admin API](/flagsmith-integration/flagsmith-api-overview/admin-api) key to a specific set of permissions.
+- Lock down an [Admin API](/integrating-with-flagsmith/flagsmith-api-overview/admin-api) key to a specific set of permissions.
 - Provide Flagsmith permissions based on your enterprise identity provider's groups when using
   [SAML single sign-on](/administration-and-security/access-control/saml).
 
@@ -51,7 +51,7 @@ following built-in roles:
 - _Organisation Administrator_ grants full access to everything in your Flagsmith organisation.
 - _User_ grants no access and requires you to assign permissions using custom roles and/or groups.
 
-**Custom roles** can be assigned to users, groups or [Admin API](/flagsmith-integration/flagsmith-api-overview/admin-api) keys. Any
+**Custom roles** can be assigned to users, groups or [Admin API](/integrating-with-flagsmith/flagsmith-api-overview/admin-api) keys. Any
 number of custom roles can be created and assigned.
 
 Creating, modifying or assigning roles requires organisation administrator permissions.

docs/docs/administration-and-security/billing-api-usage.md

@@ -31,7 +31,7 @@ The following screenshot shows an example usage graph from the Flagsmith dashboa
 
 When your application is integrated with Flagsmith, it makes requests to the Flagsmith API to perform actions such as
 retrieving the current state of its flags. Some of these actions count towards your limit of billable API requests. The
-billable API requests that your application makes depend mainly on which [flag evaluation mode](/flagsmith-integration/integration-overview) it uses.
+billable API requests that your application makes depend mainly on which [flag evaluation mode](/integrating-with-flagsmith/integration-overview) it uses.
 
 **Remote Evaluation** is the default for all applications. Applications using Remote Evaluation call the Flagsmith API
   when they need to fetch the flags for the current environment or user.
@@ -45,7 +45,7 @@ default) to fetch the flags for the current environment and all users in one API
 
 The following requests are not billable:
 
-- [Admin API](/flagsmith-integration/flagsmith-api-overview/admin-api) requests.
+- [Admin API](/integrating-with-flagsmith/flagsmith-api-overview/admin-api) requests.
 - Requests made by Flagsmith SDKs to track [Flag Analytics](/experimentation/flag-analytics).
 - Connecting to a [real-time flag updates](/performance/real-time-flags) stream.
 
@@ -117,11 +117,11 @@ application. For example, when a user visits a certain part of your application
 a mobile application is brought to the foreground.
 * Consider using an Edge Proxy as your source of flags instead of calling the Flagsmith API directly.
 * If you have a suitable backend, consider evaluating flags server-side instead. This enables other usage patterns that
-result in fewer API calls, such as [Local Evaluation](/flagsmith-integration/integration-overview#local-evaluation-mode) and custom cache implementations.
+result in fewer API calls, such as [Local Evaluation](/integrating-with-flagsmith/integration-overview#local-evaluation-mode) and custom cache implementations.
 
 For server-side applications:
 
-* Consider using [Local Evaluation](/flagsmith-integration/integration-overview#local-evaluation-mode), or deploying [Edge Proxies](/performance/edge-proxy).
+* Consider using [Local Evaluation](/integrating-with-flagsmith/integration-overview#local-evaluation-mode), or deploying [Edge Proxies](/performance/edge-proxy).
 * Reduce the polling rate for Edge Proxies and any SDKs using Local Evaluation.
 * If your use case allows for it, use the Flagsmith SDK in Offline Mode.
 

docs/docs/administration-and-security/data-management/import-and-export.md

@@ -17,7 +17,7 @@ There are several ways of importing or exporting Flagsmith data:
   between Flagsmith projects.
 * [Organisation import/export](organisations-import-export). Export an entire 
   Flagsmith organisation and copy it to a different Flagsmith instance.
-* Use the [Admin API](/flagsmith-integration/flagsmith-api-overview/admin-api) to manually manage your Flagsmith data.
+* Use the [Admin API](/integrating-with-flagsmith/flagsmith-api-overview/admin-api) to manually manage your Flagsmith data.
 
 ## Import from third-party services
 

docs/docs/administration-and-security/governance-and-compliance/api-usage.md

@@ -7,7 +7,7 @@ Flagsmith will track API calls made by the SDKS and store them in its data-store
 1. Get Flags
 2. Get Identity Flags
 3. Set Identity Traits
-4. Get [Environment Document](/flagsmith-integration/integration-overview) (for local evaluation SDKs)
+4. Get [Environment Document](/integrating-with-flagsmith/integration-overview) (for local evaluation SDKs)
 
 ![API Usage](/img/api-usage.png)
 

docs/docs/administration-and-security/governance-and-compliance/custom-fields.md

@@ -69,7 +69,7 @@ Custom fields are mainly intended to be read by humans visiting the Flagsmith da
 
 Custom field values associated with features belong to the features themselves, and not an environment's feature state; you cannot override custom field values in different environments, segments or identities. They are not returned to applications that consume flags.
 
-Custom field values are added directly to the `metadata` field of the entity they are defined in, which can be read using the [Flagsmith Admin API](/flagsmith-integration/flagsmith-api-overview/admin-api). For example, to fetch a feature's custom fields, use the [endpoint to fetch a feature by ID](https://api.flagsmith.com/api/v1/docs/#/api/api_v1_projects_features_read):
+Custom field values are added directly to the `metadata` field of the entity they are defined in, which can be read using the [Flagsmith Admin API](/integrating-with-flagsmith/flagsmith-api-overview/admin-api). For example, to fetch a feature's custom fields, use the [endpoint to fetch a feature by ID](https://api.flagsmith.com/api/v1/docs/#/api/api_v1_projects_features_read):
 
 ```shell
 curl "https://api.flagsmith.com/api/v1/projects/YOUR_PROJECT_ID/features/YOUR_FEATURE_ID/" \

docs/docs/administration-and-security/governance-and-compliance/security.md

@@ -10,7 +10,7 @@ There may be use-cases where you want to prevent client-side SDKs from setting t
 setting `plan=silver` as a trait, and then enabling/disabling features based on that plan, a malicious user could, with
 a client-side SDK, update their trait to `plan=gold` and unlock features they have not paid for.
 
-You can prevent this by disabling the "Persist traits when using client-side SDK keys" option. This option defaults to "On". Turning it "Off" will not allow client-side SDKs to write traits to Flagsmith. In order to write traits, you will need to use a [server-side SDK and server-side Key](/flagsmith-integration/integration-overview).
+You can prevent this by disabling the "Persist traits when using client-side SDK keys" option. This option defaults to "On". Turning it "Off" will not allow client-side SDKs to write traits to Flagsmith. In order to write traits, you will need to use a [server-side SDK and server-side Key](/integrating-with-flagsmith/integration-overview).
 
 This is a per-Environment setting.
 

docs/docs/administration-and-security/governance-and-compliance/system-limits.md

@@ -75,7 +75,7 @@ the end of your billing period.
 
 ### Admin API Rate Limit
 
-Requests made to [Admin API endpoints](/flagsmith-integration/flagsmith-api-overview/admin-api) (i.e., non-SDK endpoints) are subject
+Requests made to [Admin API endpoints](/integrating-with-flagsmith/flagsmith-api-overview/admin-api) (i.e., non-SDK endpoints) are subject
 to a default rate limit of 500 requests per minute.
 
 If you are self-hosting, you have the flexibility to modify this limit by adjusting the value of the environment

docs/docs/administration-and-security/index.mdx

@@ -33,21 +33,21 @@ Configure how users log in and what they can access within your Flagsmith organi
 <Card>
   <div className="card-header flex-column">
     <div className="icon-container">
-      <IonIcon icon={key} className="card-icon" />
+      <IonIcon icon={people} className="card-icon" />
     </div>
-    <h3><Link to="/administration-and-security/access-control/">Authentication Management</Link></h3>
+    <h3><Link to="/administration-and-security/access-control/rbac">User Management & Permissions</Link></h3>
   </div>
-  <p>Set up authentication methods including SSO, SAML, LDAP, and 2FA</p>
+  <p>Control user roles, groups, and fine-grained permissions</p>
 </Card>
 
 <Card>
   <div className="card-header flex-column">
     <div className="icon-container">
-      <IonIcon icon={people} className="card-icon" />
+      <IonIcon icon={key} className="card-icon" />
     </div>
-    <h3><Link to="/administration-and-security/access-control/rbac">User Management & Permissions</Link></h3>
+    <h3><Link to="/administration-and-security/access-control/">Authentication Management</Link></h3>
   </div>
-  <p>Control user roles, groups, and fine-grained permissions</p>
+  <p>Set up authentication methods including SSO, SAML, LDAP, and 2FA</p>
 </Card>
 
 <Card>

docs/docs/best-practices/defensive-coding.md

@@ -27,7 +27,7 @@ So with that in mind, here are some rules you can follow to avoid any issues ste
 
 The solution here really depends on which of our SDKs you are using. By default our Client SDKs will not block your main application thread, and are designed to work around an asynchronous callback model.
 
-Where our Server Side SDKs are being used, it really depends on if you are using them in [local or remote evaluation mode](/flagsmith-integration/integration-overview). When running in local evaluation mode, once the SDKs have received a response from the API with the Environment related data, they will keep that data in memory. In the event of the SDKs then not receiving an update, they will continue to function.
+Where our Server Side SDKs are being used, it really depends on if you are using them in [local or remote evaluation mode](/integrating-with-flagsmith/integration-overview). When running in local evaluation mode, once the SDKs have received a response from the API with the Environment related data, they will keep that data in memory. In the event of the SDKs then not receiving an update, they will continue to function.
 
 In the event that the SDKs aren't able to contact the API at all, they will time out and resort to [Default flags](#progressively-enhance-your-application-with-default-flags). When running in remote evaluation mode, you will need to decide what the best approach is based on your particular application. Again, [Default flags](#progressively-enhance-your-application-with-default-flags) can help here.
 
@@ -57,7 +57,7 @@ In addition to this, by default our client-sde SDKs will only make a network cal
 
 ### Server side SDKs and local evaluation mode
 
-If you need sub-millisecond latency for end-to-end flag evaluation, for example in the event that you are running a multi-variate test on a landing page of your website, you can employ one of our Server Side SDKs running in [local evaluation mode](/flagsmith-integration/integration-overview) mode. This will provide sub-millisecond latency of the entire flag evaluation rules engine, running locally within your server infrastructure, allowing you to run multivariate tests with zero latency impact.
+If you need sub-millisecond latency for end-to-end flag evaluation, for example in the event that you are running a multi-variate test on a landing page of your website, you can employ one of our Server Side SDKs running in [local evaluation mode](/integrating-with-flagsmith/integration-overview) mode. This will provide sub-millisecond latency of the entire flag evaluation rules engine, running locally within your server infrastructure, allowing you to run multivariate tests with zero latency impact.
 
 ### No proxy-server required