add new APIs + add multiple workflow docs

api-reference/assets/create-asset-policy.mdx

@@ -0,0 +1,3 @@
+---
+openapi: post /v1/asset/policy
+---

api-reference/assets/delete-asset-policy.mdx

@@ -0,0 +1,3 @@
+---
+openapi: delete /v1/asset/policy/{policy_id}
+---

api-reference/assets/get-asset-policy-events.mdx

@@ -0,0 +1,3 @@
+---
+openapi: get /v1/asset/policy/{policy_id}/events
+---

api-reference/assets/get-asset-policy-suggestions.mdx

@@ -0,0 +1,3 @@
+---
+openapi: get /v1/asset/policy/suggestion
+---

api-reference/assets/get-asset-policy.mdx

@@ -0,0 +1,3 @@
+---
+openapi: get /v1/asset/policy/{policy_id}
+---

api-reference/assets/list-asset-policies.mdx

@@ -0,0 +1,3 @@
+---
+openapi: get /v1/asset/policy
+---

api-reference/assets/update-asset-policy.mdx

@@ -0,0 +1,3 @@
+---
+openapi: patch /v1/asset/policy/{policy_id}
+---

api-reference/enumerations/list-enumeration-misconfigurations.mdx

@@ -0,0 +1,3 @@
+---
+openapi: get /v1/asset/enumerate/misconfiguration
+---

api-reference/internal/search-audit-logs.mdx

@@ -0,0 +1,3 @@
+---
+openapi: get /v1/team/audit_log/search
+---

api-reference/results/get-vulnerability-timeline.mdx

@@ -0,0 +1,3 @@
+---
+openapi: get /v2/vulnerability/{id}/timeline
+---

cloud/assets/exclusions.mdx

@@ -8,6 +8,8 @@ sidebarTitle: "Target Exclusions"
 
 Discovery Target Exclusions allow you to proactively prevent specific assets or patterns from being discovered during asset enumeration. When exclusions are configured, these targets are actively filtered out of the discovery process, helping you focus on relevant assets and reduce noise in your asset inventory.
 
+This feature also supports **inclusion patterns** (prefixed with `+`) that restrict discovery to only matching targets, functioning as an allowlist. See [Inclusion Patterns](#inclusion-patterns) for details.
+
 This feature is particularly useful for excluding internal staging environments, test domains, government domains, or any other assets that should not be included in your attack surface monitoring.
 
 <Note>
@@ -76,6 +78,89 @@ dev-*.internal.company.com
 *.edu
 ```
 
+## Inclusion Patterns
+
+### Overview
+
+In addition to excluding targets, you can use **inclusion patterns** to create an allowlist — restricting discovery to only the targets that match your specified patterns. This is done by prefixing patterns with `+` in the `exclusions` field when creating an enumeration via the API.
+
+<Important>
+  **Allowlist Behavior**: When any inclusion pattern (prefixed with `+`) is present, the system switches to allowlist mode. Targets that do **not** match at least one inclusion pattern are automatically filtered out — even if they aren't matched by any exclusion pattern.
+</Important>
+
+### How Inclusion Works
+
+When inclusion patterns are configured:
+
+1. **Inclusion check first**: Each discovered target is checked against all `+` patterns. If the target does not match any inclusion pattern, it is filtered out.
+2. **Exclusion check second**: Targets that pass the inclusion check are then checked against exclusion patterns (without `+` prefix). If a target matches an exclusion, it is still filtered out.
+
+<Note>
+  **API-Only Feature**: Inclusion patterns are configured through the API's `exclusions` field when creating an enumeration (POST /enumerate). They use the same field as exclusion patterns — the `+` prefix distinguishes inclusions from exclusions.
+</Note>
+
+### Inclusion Pattern Examples
+
+#### Include Only Production Targets
+Restrict discovery to production subdomains only:
+```
++prod-*.company.com
++api.company.com
++*.production.company.com
+```
+
+#### Include Specific IP Range
+Restrict discovery to a specific network segment:
+```
++10.0.1.0/24
++192.168.100.0/24
+```
+
+#### Combined Inclusion and Exclusion
+Include production systems but exclude a specific staging subdomain that matches the pattern:
+```
++prod-*.company.com
++api.company.com
+*.staging.company.com
+```
+
+In this example:
+- `prod-web.company.com` → **discovered** (matches inclusion `+prod-*.company.com`)
+- `api.company.com` → **discovered** (matches inclusion `+api.company.com`)
+- `prod-web.staging.company.com` → **filtered out** (matches inclusion, but also matches exclusion `*.staging.company.com`)
+- `other.company.com` → **filtered out** (does not match any inclusion pattern)
+
+### Inclusion Use Cases
+
+<AccordionGroup>
+  <Accordion title="Scoping to Production Only">
+    Restrict discovery to production infrastructure:
+    ```
+    +*.prod.company.com
+    +api.company.com
+    +payments.company.com
+    ```
+  </Accordion>
+
+  <Accordion title="Network Segment Discovery">
+    Discover assets only in specific network segments:
+    ```
+    +10.0.1.0/24
+    +10.0.2.0/24
+    ```
+  </Accordion>
+
+  <Accordion title="Combined Scoping">
+    Include a broad set of targets but exclude specific subsets:
+    ```
+    +*.company.com
+    *.internal.company.com
+    *.dev.company.com
+    ```
+    This discovers all `company.com` subdomains except internal and dev environments.
+  </Accordion>
+</AccordionGroup>
+
 ## Pattern Syntax
 
 ### Wildcard Support
@@ -86,10 +171,25 @@ The exclusion system supports wildcard patterns using the asterisk (`*`) charact
 - **Suffix wildcards**: `test.*.company.com` - Excludes any subdomain starting with `test.` and ending with `.company.com`
 - **Multiple wildcards**: `*.staging.*.company.com` - Supports multiple wildcards in a single pattern
 
+### Inclusion Prefix
+
+Inclusion patterns use the same syntax as exclusions, prefixed with `+`:
+
+- **Exact match**: `+api.company.com`
+- **Wildcard**: `+prod-*.company.com`
+- **CIDR range**: `+10.0.0.0/24`
+- **IP address**: `+192.168.1.100`
+
+<Note>
+  Inclusion and exclusion patterns can be mixed in the same `exclusions` field. The `+` prefix is what distinguishes an inclusion from an exclusion.
+</Note>
+
 ### Pattern Matching Rules
 
 - Patterns are **case-insensitive**
-- Each line represents a separate exclusion pattern
+- Each line represents a separate pattern
+- Inclusion patterns use the `+` prefix with the same wildcard and CIDR support as exclusions
+- When inclusion patterns are present, targets must match at least one inclusion pattern **and** not match any exclusion pattern
 - Patterns are matched during the discovery phase
 - Once excluded, targets will not appear in any subsequent discovery results
 
@@ -131,6 +231,13 @@ The exclusion system supports wildcard patterns using the asterisk (`*`) charact
     - Group similar patterns together for better organization
     - Regularly review and update exclusion patterns as your infrastructure evolves
   </Accordion>
+
+  <Accordion title="Inclusion Pattern Strategy">
+    Use inclusion patterns when you want to restrict discovery scope rather than exclude individual targets:
+    - Prefer inclusions over large exclusion lists when you want to discover a small subset of a broad target list
+    - Combine inclusions with exclusions to create precise scoping (e.g., include all production but exclude a specific staging subdomain)
+    - Start with broader inclusion patterns and add exclusions for specific exceptions
+  </Accordion>
 </AccordionGroup>
 
 ## Important Considerations

cloud/integrations.mdx

@@ -913,6 +913,131 @@ After configuring the integration, it's important to verify that ProjectDiscover
 
 If all checks out, ProjectDiscovery is now actively monitoring your AWS environment. New resources launched in AWS should be detected on the next scan cycle, and any changes to your cloud footprint will be reflected in the platform. Make sure to regularly review the integration and update the IAM permissions if you start using new AWS services.
 
+#### API Setup
+
+You can set up the AWS integration entirely through the API. The process involves creating a cloudlist configuration, verifying it, and then using it to create an enumeration.
+
+The cloudlist configuration is a YAML array that must be **base64-encoded** before sending it to the API. Each connection method uses a different YAML structure, but the API calls are the same.
+
+**Configuration Format**
+
+<AccordionGroup>
+  <Accordion title="Single AWS Account (Access Key & Secret)">
+    ```yaml
+    - provider: aws
+      aws_access_key: "AKIAIOSFODNN7EXAMPLE"
+      aws_secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
+      aws_session_token: "optional-session-token"
+      services:
+        - ec2
+        - route53
+        - s3
+    ```
+  </Accordion>
+
+  <Accordion title="Multiple AWS Accounts (Assume Role)">
+    ```yaml
+    - provider: aws
+      aws_access_key: "AKIAIOSFODNN7EXAMPLE"
+      aws_secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
+      assume_role_name: "ProjectDiscoveryReadOnlyRole"
+      account_ids:
+        - "123456789012"
+        - "987654321098"
+      services:
+        - ec2
+        - route53
+        - s3
+    ```
+  </Accordion>
+
+  <Accordion title="Cross-Account Role (Role ARN)">
+    ```yaml
+    - provider: aws
+      assume_role_arn: "arn:aws:iam::123456789012:role/ProjectDiscoveryRole"
+      external_id: "your-external-id"
+      assume_role_session_name: "projectdiscovery_role"
+      services:
+        - ec2
+        - route53
+        - s3
+    ```
+
+    The `external_id` is displayed in the ProjectDiscovery UI when you select the Cross-Account Role method. You can also retrieve it from your account settings.
+  </Accordion>
+</AccordionGroup>
+
+<Note>
+  The YAML configuration must be **base64-encoded** before passing it as the `config` field in the API request. For example, using the command line: `cat config.yaml | base64`.
+</Note>
+
+**Step 1: Verify the Configuration**
+
+<Note>
+  While verification is optional, it is strongly recommended before creating the integration. This step validates that the credentials are correct and that ProjectDiscovery can successfully connect to your AWS account, saving you from debugging failed enumerations later.
+</Note>
+
+```bash
+curl -X POST https://api.projectdiscovery.io/v1/scans/config/verify \
+  -H 'Content-Type: application/json' \
+  -H 'X-API-Key: <your-api-key>' \
+  -d '{
+    "config_type": "cloudlist",
+    "config": "<base64-encoded-yaml>"
+  }'
+```
+
+A successful response:
+
+```json
+{
+  "is_verified": true,
+  "response": "config verified successfully"
+}
+```
+
+If verification fails, check your credentials, IAM permissions, and role trust policies before proceeding.
+
+**Step 2: Create the Integration**
+
+Once verified, send the base64-encoded configuration to create a cloudlist config:
+
+```bash
+curl -X POST https://api.projectdiscovery.io/v1/scans/config \
+  -H 'Content-Type: application/json' \
+  -H 'X-API-Key: <your-api-key>' \
+  -d '{
+    "name": "My AWS Integration",
+    "config_type": "cloudlist",
+    "config": "<base64-encoded-yaml>"
+  }'
+```
+
+The response includes the config `id` that you will use in the next step:
+
+```json
+{
+  "id": "config-id",
+  "message": "successfully created configuration"
+}
+```
+
+**Step 3: Create an Enumeration**
+
+Use the config `id` from Step 2 to create a cloud asset enumeration:
+
+```bash
+curl -X POST https://api.projectdiscovery.io/v1/asset/enumerate \
+  -H 'Content-Type: application/json' \
+  -H 'X-API-Key: <your-api-key>' \
+  -d '{
+    "cloudlist_config_ids": ["<config-id-from-step-2>"],
+    "name": "AWS Cloud Enumeration"
+  }'
+```
+
+The example above shows a minimal request. Refer to the [Create Enumeration API reference](/api-reference/enumerations/create-enumeration) for the complete list of required and optional fields.
+
 **References:**
 
 1. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_read-only-console.html