diff --git a/auth/ntlm.mdx b/auth/ntlm.mdx
index 8353b108..46256076 100644
--- a/auth/ntlm.mdx
+++ b/auth/ntlm.mdx
@@ -23,3 +23,16 @@ Follow these steps to use NTLM authentication:
- **Domain**: Your Windows domain name
+
+## How Bruno handles NTLM requests
+
+NTLM requests run through Bruno's standard request pipeline. Your TLS settings, custom CA certificates, client certificates, and proxy configuration all apply to NTLM requests, and the full handshake is visible in the **Timeline** tab.
+
+Because NTLM authenticates the connection rather than the individual request, Bruno keeps the entire handshake on a single connection.
+
+### Redirect behavior
+
+When a server redirects an NTLM-authenticated request:
+
+- **Same origin**: Bruno renegotiates the NTLM handshake on the new connection and follows the redirect.
+- **Different host**: Bruno follows the redirect without authenticating, so the response is the target's `401` challenge. To renegotiate NTLM with the other host, enable the request's `forwardAuthorizationHeader` setting.
diff --git a/get-started/import-export-data/import-export-environments.mdx b/get-started/import-export-data/import-export-environments.mdx
index 592e4cd4..3ca756e0 100644
--- a/get-started/import-export-data/import-export-environments.mdx
+++ b/get-started/import-export-data/import-export-environments.mdx
@@ -19,7 +19,7 @@ You can import and export environment variables (collection and global) to share
## Importing Environment Variables
-The import feature accepts environment files in both **Bruno** and **Postman** formats.
+The import feature accepts environment files in both **Bruno** and **Postman** formats. You can import multiple files at once.
### Steps to Import
@@ -27,11 +27,26 @@ The import feature accepts environment files in both **Bruno** and **Postman** f
-2. Select the environment file you want to import.
-3. The variables will be added to your environment (global or collection, depending on which you're configuring).
+2. Drag and drop one or more JSON environment files, or click to browse and select them.
+3. The environments will be added (global or collection, depending on which you're configuring). If none of the names conflict with existing environments and all files are valid, Bruno imports them immediately.
+### Resolving name conflicts
+
+If an imported environment has the same name as an existing one, Bruno shows a review screen before importing. The screen groups environments into **Duplicates** and **New**, and lets you search the list and select which environments to import.
+
+For each duplicate, choose one of two resolutions:
+
+- **Import as copy** (default): Bruno creates the environment under a new name and keeps the existing environment untouched.
+- **Replace existing**: Bruno overwrites the existing environment's variables with the imported ones.
+
+You can also apply a resolution to all duplicates at once using the dropdown in the **Duplicates** group header. Click **Import** to finish.
+
+
+ If a file has an invalid or unsupported format, Bruno reports the error and continues importing the remaining valid files.
+
+
## Exporting Environment Variables
### Steps to Export
diff --git a/mock-servers/create-mock-server.mdx b/mock-servers/create-mock-server.mdx
index bc3d5c79..f8509c1a 100644
--- a/mock-servers/create-mock-server.mdx
+++ b/mock-servers/create-mock-server.mdx
@@ -21,8 +21,8 @@ Use this path when the collection already has saved response examples.
1. Open the collection.
2. In the sidebar, expand **Mock Servers** and click the **+** icon to create a new mock server.
3. Enter a **Name**.
-4. Keep **Link to a collection or API spec** checked, select **Collection**, pick the collection, then click **Create**.
-5. On the dashboard, click **Sync with Examples**. Every [saved example](/send-requests/res-data-cookies/response-examples) becomes a mock response (method, path, status, headers, and body).
+4. Under **Source**, select **Collection** and pick the collection.
+5. Keep **Sync mock responses with collection examples** checked, then click **Create**. Every [saved example](/send-requests/res-data-cookies/response-examples) becomes a mock response (method, path, status, headers, and body). If you uncheck it, you can sync later from the dashboard with **Sync with Examples**.
6. Click **Start Server** to start the mock server on the saved port. If the port is already in use, change it under **Mock Server Settings (gear icon)** → **Advanced settings**.
@@ -33,8 +33,8 @@ Use this path when the collection already has saved response examples.
Use this path when you have an API spec in the workspace. Turn on [API Spec](/open-api/createOAS#viewing-existing-oas-files) under **Preferences** → **Features** if it is not already enabled.
1. Load the spec under **API Specs** in the sidebar (if it is not already there).
-2. Create a mock server, keep **Link to a collection or API spec** checked, select **API Spec**, pick the spec, then click **Create**.
-3. On the dashboard, click **Generate from API Spec**. Each operation and response status becomes a mock response; bodies are derived from the schema where possible.
+2. Create a mock server. Under **Source**, select **API Spec** and pick the spec.
+3. Keep **Sync mock responses with API spec** checked, then click **Create**. Each operation and response status becomes a mock response; bodies are derived from the schema where possible. If you uncheck it, you can generate later from the dashboard with **Generate from API Spec**.
4. Click **Start Server** to start the mock server on the saved port. If the port is already in use, change it under **Mock Server Settings (gear icon)** → **Advanced settings**.
@@ -46,12 +46,16 @@ To add responses yourself instead of syncing from a collection or spec:
1. Click **+** under **Mock Servers**.
2. Enter a **Name**.
-3. Turn off **Link to a collection or API spec**.
+3. Under **Source**, select **Standalone**.
4. Optionally set **Port** and **Response delay** under **Advanced settings**.
5. Click **Create**, then add responses from the **Responses** tab.
+## Port validation
+
+The port must be a whole number between 1 and 65535. Bruno validates the port when you create, clone, or edit a mock server and when you start it, and shows an error if the port is already used by another mock server in Bruno or by another process on your system.
+
## Where Bruno store mock servers
Mock servers are stored in the workspace at the root of the **mocks** folder. After creation, the mock server is saved as a .yml file.
diff --git a/send-requests/REST/req-header.mdx b/send-requests/REST/req-header.mdx
index 8bb51432..98b8b723 100644
--- a/send-requests/REST/req-header.mdx
+++ b/send-requests/REST/req-header.mdx
@@ -18,11 +18,32 @@ Request headers are **key-value** pairs sent along with an HTTP request to provi
+## View default headers
+
+Bruno adds a set of default headers, such as `User-Agent`, `Accept`, `Accept-Encoding`, `Connection`, and `Host`, to every request at runtime. You can view them directly in the **Headers** tab:
+
+1. Navigate to the **Headers** tab.
+2. Click **Show Inherited Headers** at the bottom of the tab.
+
+The tab now shows an **Inherited Headers** section with the default headers and a **Request Headers** section with your own headers. Click **Hide Inherited Headers** to collapse the view.
+
- To view default headers, navigate to the **Headers** tab in your request. For
- custom headers, check the **Timeline** tab.
+ To verify the headers that were actually sent with a request, check the **Timeline** tab.
+### Omit a default header
+
+You can omit individual default headers on a per-request basis:
+
+1. Click **Show Inherited Headers** in the **Headers** tab.
+2. Uncheck the default header you want to omit.
+
+Bruno saves the omitted headers in the request file and skips them when sending the request, both in the app and in the [Bruno CLI](/bru-cli/overview).
+
+
+ Adding your own header with the same name overrides the default header. Bruno shows a warning icon next to both headers when this happens. The `Host` header is required by HTTP and cannot be omitted.
+
+
## Streaming with Server-Sent Events
To work with Server-Sent Events (SSE), set:
diff --git a/variables/overview.mdx b/variables/overview.mdx
index 5ceb2b0e..f111339d 100644
--- a/variables/overview.mdx
+++ b/variables/overview.mdx
@@ -23,6 +23,20 @@ Additionally, Process Environment Variables can be defined in an external enviro
- [Process Environment Variables](./process-env)
+### Creating Variables Inline
+
+When you type an undefined `{{variable}}` in a request, Bruno highlights it and shows a tooltip. You can create the variable directly from this tooltip instead of navigating to the scope where it should live:
+
+1. Hover over the undefined variable to open the tooltip.
+2. Select the scope for the variable:
+ - **Request**: available when you are inside a request.
+ - **Collection**: always available.
+ - **Environment** and **Global**: available when an active environment exists. If none is active, you can create one from the same tooltip.
+3. Enter the value. For the Environment and Global scopes, you can mark the variable as a **Secret** to mask its value.
+4. Click outside the tooltip to save the variable.
+
+Once a variable is defined, its name in the tooltip becomes a link that navigates to the scope where it is defined.
+
### Variable Precedence and Scope
When a variable is accessed, the following precedence is used to determine which value is used: