diff --git a/content/send-notifications/testing-workflows.mdx b/content/send-notifications/testing-workflows.mdx
index aa348b088..19f6cbf7e 100644
--- a/content/send-notifications/testing-workflows.mdx
+++ b/content/send-notifications/testing-workflows.mdx
@@ -24,6 +24,15 @@ Note that [trigger frequency](/send-notifications/triggering-workflows/overview#
 
 You can also use the workflow test runner to run a test payload for a [source event trigger](/integrations/sources/overview#workflow-triggers). If your workflow is triggered by an event, you will automatically see a JSON payload of the last received event that you can use to run a test. You can edit this payload or click "Fetch the latest event" to get the most recent from your source.
 
+### Test run settings
+
+The test runner includes a few settings that control how the workflow executes during a test run:
+
+- **Sandbox mode.** When enabled, all messages sent from the workflow are forced to send in [sandbox mode](/integrations/overview#sandbox-mode). Knock generates and previews the messages without delivering them to the underlying providers, regardless of how sandbox mode is configured on each channel. This is useful for testing a workflow end-to-end without sending real notifications to your recipients.
+- **Skip delays.** When enabled, all [delay steps](/designing-workflows/delay-function) in the workflow are force skipped. The workflow runs straight through without waiting, which lets you verify the full execution path without waiting for delays to elapse.
+
+You can also apply both of these settings when triggering a workflow via the API using the `settings.sandbox_mode` and `settings.skip_delay` properties, which is useful when testing workflows programmatically.
+
 <Callout
   type="alert"
   title="Note:"
diff --git a/content/send-notifications/triggering-workflows/api.mdx b/content/send-notifications/triggering-workflows/api.mdx
index 50a013454..8d827a9c9 100644
--- a/content/send-notifications/triggering-workflows/api.mdx
+++ b/content/send-notifications/triggering-workflows/api.mdx
@@ -24,6 +24,7 @@ Learn more about triggering workflows in [our API reference](/api-reference/work
 | data             | map                   | A map of properties that are required in the templates in this workflow                                     |
 | cancellation_key | string                | A unique identifier to reference the workflow when canceling                                                |
 | tenant           | string                | An optional identifier of the owning tenant object for the notifications generated during this workflow run |
+| settings         | map                   | An optional map of settings that control how this workflow run is executed                                  |
 
 ## Recipient identifiers
 
@@ -207,6 +208,28 @@ tenants to which they belong in your product.
 
 You can read more about [supporting multi-tenancy in our documentation](/concepts/tenants).
 
+## Testing workflows with trigger settings
+
+You can pass an optional `settings` object in your `trigger` call to control how the workflow run is executed. These settings are useful when testing a workflow, and mirror the options available in the [workflow test runner](/send-notifications/testing-workflows#test-run-settings).
+
+| Property     | Type    | Description                                                                                                                                                                                                                                                   |
+| ------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| sandbox_mode | boolean | When `true`, all messages in the workflow run are forced to send in [sandbox mode](/integrations/overview#sandbox-mode), overriding the per-channel configuration. Messages are generated but not delivered to the underlying providers. Defaults to `false`. |
+| skip_delay   | boolean | When `true`, all [delay steps](/designing-workflows/delay-function) in the workflow are force skipped, so the run executes straight through without waiting. Defaults to `false`.                                                                             |
+
+```json title="Example trigger with settings"
+{
+  "recipients": ["user-1"],
+  "data": {
+    "message": "Life finds a way"
+  },
+  "settings": {
+    "sandbox_mode": true,
+    "skip_delay": true
+  }
+}
+```
+
 ## Frequently asked questions
 
 <AccordionGroup>