add http trigger guides

Author: khadni

reports/llms-report.json

@@ -1,22 +1,22 @@
 {
-  "startedAt": "2025-11-11T01:58:33.890Z",
+  "startedAt": "2025-11-11T12:13:25.939Z",
   "siteBase": "https://docs.chain.link",
   "sections": [
     {
       "section": "cre-go",
       "pagesProcessed": 84,
       "outputPath": "src/content/cre/llms-full-go.txt",
-      "bytes": 631871,
+      "bytes": 632196,
       "prevBytes": 631871,
-      "deltaBytes": 0
+      "deltaBytes": 325
     },
     {
       "section": "cre-ts",
       "pagesProcessed": 79,
       "outputPath": "src/content/cre/llms-full-ts.txt",
-      "bytes": 587337,
+      "bytes": 587662,
       "prevBytes": 587337,
-      "deltaBytes": 0
+      "deltaBytes": 325
     },
     {
       "section": "vrf",
@@ -123,5 +123,5 @@
       "deltaBytes": 0
     }
   ],
-  "finishedAt": "2025-11-11T01:58:38.894Z"
+  "finishedAt": "2025-11-11T12:13:30.721Z"
 }

src/content/cre/guides/workflow/using-triggers/http-trigger/configuration-go.mdx

@@ -78,7 +78,7 @@ func InitWorkflow(config *Config, logger *slog.Logger, secretsProvider cre.Secre
 - **`Type`**: Must be `http.KeyType_KEY_TYPE_ECDSA_EVM` (currently the only supported authentication method)
 - **Multiple keys**: You can include multiple authorized addresses in the slice
 
-When an HTTP request is made to your workflow's endpoint, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
+When an HTTP request is made to trigger your workflow, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
 
 ## Callback and payload
 

src/content/cre/guides/workflow/using-triggers/http-trigger/configuration-ts.mdx

@@ -75,7 +75,7 @@ main()
 - **`type`**: Must be `"KEY_TYPE_ECDSA_EVM"` (currently the only supported authentication method)
 - **Multiple keys**: You can include multiple authorized addresses in the array
 
-When an HTTP request is made to your workflow's endpoint, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
+When an HTTP request is made to trigger your workflow, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
 
 ## Callback and payload
 

src/content/cre/guides/workflow/using-triggers/http-trigger/overview-go.mdx

@@ -20,7 +20,7 @@ When you deploy a workflow with an HTTP trigger:
 
 1. **External systems send HTTP POST requests** to a CRE gateway
 1. **The request specifies your workflow ID** in the JSON-RPC body along with the input payload
-1. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address
+1. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address in the target workflow
 1. **CRE validates the signature** against your configured `authorizedKeys`
 1. **If authorized**, your workflow callback executes with the request payload
 
@@ -37,7 +37,7 @@ HTTP triggers are ideal for:
 - **Webhook integration**: Receive events from external services (GitHub, payment processors, etc.)
 - **On-demand execution**: Allow users or systems to trigger specific workflow logic when needed
 - **API gateway patterns**: Create authenticated endpoints that execute blockchain operations
-- **Event bridging**: Connect web2 events to web3 workflows
+- **Event bridging**: Connect offchain systems events to workflows
 
 ## The complete HTTP trigger journey
 

src/content/cre/guides/workflow/using-triggers/http-trigger/overview-ts.mdx

@@ -20,7 +20,7 @@ When you deploy a workflow with an HTTP trigger:
 
 1. **External systems send HTTP POST requests** to a CRE gateway
 1. **The request specifies your workflow ID** in the JSON-RPC body along with the input payload
-1. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address
+1. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address in the target workflow
 1. **CRE validates the signature** against your configured `authorizedKeys`
 1. **If authorized**, your workflow callback executes with the request payload
 
@@ -37,7 +37,7 @@ HTTP triggers are ideal for:
 - **Webhook integration**: Receive events from external services (GitHub, payment processors, etc.)
 - **On-demand execution**: Allow users or systems to trigger specific workflow logic when needed
 - **API gateway patterns**: Create authenticated endpoints that execute blockchain operations
-- **Event bridging**: Connect web2 events to web3 workflows
+- **Event bridging**: Connect offchain systems events to workflows
 
 ## The complete HTTP trigger journey
 

src/content/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation.mdx

@@ -88,9 +88,11 @@ cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --htt
 
 For complex payloads or reusable test data, store your JSON in a file and reference it in non-interactive mode.
 
-**Create a payload file** in your project root (the directory where you run `cre workflow simulate`):
+**Option 1: File in workflow folder**
 
-**`test-payload.json`:**
+Create the payload file in your workflow directory:
+
+**`my-http-workflow/test-payload.json`:**
 
 ```json
 {
@@ -104,18 +106,25 @@ For complex payloads or reusable test data, store your JSON in a file and refere
 }
 ```
 
-**Simulate with file input:**
+**Simulate:**
 
 ```bash
 cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload test-payload.json --target staging-settings
 ```
 
-You can also use the `@` prefix:
+**Option 2: File at project root**
+
+Create the payload file at your project root. Simulate (using `../` to reference the parent directory):
 
 ```bash
-cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload @test-payload.json --target staging-settings
+cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload ../test-payload.json --target staging-settings
 ```
 
+<Aside type="note" title="File paths are relative to the workflow folder">
+  The CLI resolves file paths relative to the **workflow folder** you're simulating. Use just the filename for files in
+  the workflow folder, or `../filename.json` for files at the project root.
+</Aside>
+
 ## Example workflow simulation
 
 Let's simulate a complete workflow that processes HTTP requests.

src/content/cre/guides/workflow/using-triggers/http-trigger/triggering-deployed-workflows.mdx

@@ -74,8 +74,8 @@ Content-Type: application/json
 Authorization: Bearer <JWT_TOKEN>
 
 {
-  "jsonrpc": "2.0",
   "id": "unique-request-id",
+  "jsonrpc": "2.0",
   "method": "workflows.execute",
   "params": {
     "input": {

src/content/cre/llms-full-go.txt

@@ -1049,9 +1049,11 @@ cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --htt
 
 For complex payloads or reusable test data, store your JSON in a file and reference it in non-interactive mode.
 
-**Create a payload file** in your project root (the directory where you run `cre workflow simulate`):
+**Option 1: File in workflow folder**
 
-**`test-payload.json`:**
+Create the payload file in your workflow directory:
+
+**`my-http-workflow/test-payload.json`:**
 
 ```json
 {
@@ -1065,18 +1067,25 @@ For complex payloads or reusable test data, store your JSON in a file and refere
 }
 ```
 
-**Simulate with file input:**
+**Simulate:**
 
 ```bash
 cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload test-payload.json --target staging-settings
 ```
 
-You can also use the `@` prefix:
+**Option 2: File at project root**
+
+Create the payload file at your project root. Simulate (using `../` to reference the parent directory):
 
 ```bash
-cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload @test-payload.json --target staging-settings
+cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload ../test-payload.json --target staging-settings
 ```
 
+<Aside type="note" title="File paths are relative to the workflow folder">
+  The CLI resolves file paths relative to the **workflow folder** you're simulating. Use just the filename for files in
+  the workflow folder, or `../filename.json` for files at the project root.
+</Aside>
+
 ## Example workflow simulation
 
 Let's simulate a complete workflow that processes HTTP requests.
@@ -1328,8 +1337,8 @@ Content-Type: application/json
 Authorization: Bearer <JWT_TOKEN>
 
 {
-  "jsonrpc": "2.0",
   "id": "unique-request-id",
+  "jsonrpc": "2.0",
   "method": "workflows.execute",
   "params": {
     "input": {
@@ -12108,7 +12117,7 @@ func InitWorkflow(config *Config, logger *slog.Logger, secretsProvider cre.Secre
 - **`Type`**: Must be `http.KeyType_KEY_TYPE_ECDSA_EVM` (currently the only supported authentication method)
 - **Multiple keys**: You can include multiple authorized addresses in the slice
 
-When an HTTP request is made to your workflow's endpoint, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
+When an HTTP request is made to trigger your workflow, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
 
 ## Callback and payload
 
@@ -12154,12 +12163,11 @@ The HTTP trigger allows external systems to initiate your workflow execution by
 
 When you deploy a workflow with an HTTP trigger:
 
-1. **Your workflow receives a unique endpoint** managed by the CRE gateway
-2. **External systems send HTTP requests** with JSON payloads to this endpoint
-3. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address
+1. **External systems send HTTP POST requests** to a CRE gateway
+2. **The request specifies your workflow ID** in the JSON-RPC body along with the input payload
+3. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address in the target workflow
 4. **CRE validates the signature** against your configured `authorizedKeys`
 5. **If authorized**, your workflow callback executes with the request payload
-6. **Your callback's return value** becomes the HTTP response sent back to the requester
 
 <Aside type="note" title="Security by design">
   For **deployed workflows**, HTTP triggers use cryptographic signatures to ensure only authorized addresses can execute
@@ -12174,7 +12182,7 @@ HTTP triggers are ideal for:
 - **Webhook integration**: Receive events from external services (GitHub, payment processors, etc.)
 - **On-demand execution**: Allow users or systems to trigger specific workflow logic when needed
 - **API gateway patterns**: Create authenticated endpoints that execute blockchain operations
-- **Event bridging**: Connect web2 events to web3 workflows
+- **Event bridging**: Connect offchain systems events to workflows
 
 ## The complete HTTP trigger journey
 

src/content/cre/llms-full-ts.txt

@@ -1049,9 +1049,11 @@ cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --htt
 
 For complex payloads or reusable test data, store your JSON in a file and reference it in non-interactive mode.
 
-**Create a payload file** in your project root (the directory where you run `cre workflow simulate`):
+**Option 1: File in workflow folder**
 
-**`test-payload.json`:**
+Create the payload file in your workflow directory:
+
+**`my-http-workflow/test-payload.json`:**
 
 ```json
 {
@@ -1065,18 +1067,25 @@ For complex payloads or reusable test data, store your JSON in a file and refere
 }
 ```
 
-**Simulate with file input:**
+**Simulate:**
 
 ```bash
 cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload test-payload.json --target staging-settings
 ```
 
-You can also use the `@` prefix:
+**Option 2: File at project root**
+
+Create the payload file at your project root. Simulate (using `../` to reference the parent directory):
 
 ```bash
-cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload @test-payload.json --target staging-settings
+cre workflow simulate my-http-workflow --non-interactive --trigger-index 0 --http-payload ../test-payload.json --target staging-settings
 ```
 
+<Aside type="note" title="File paths are relative to the workflow folder">
+  The CLI resolves file paths relative to the **workflow folder** you're simulating. Use just the filename for files in
+  the workflow folder, or `../filename.json` for files at the project root.
+</Aside>
+
 ## Example workflow simulation
 
 Let's simulate a complete workflow that processes HTTP requests.
@@ -1316,8 +1325,8 @@ Content-Type: application/json
 Authorization: Bearer <JWT_TOKEN>
 
 {
-  "jsonrpc": "2.0",
   "id": "unique-request-id",
+  "jsonrpc": "2.0",
   "method": "workflows.execute",
   "params": {
     "input": {
@@ -11025,7 +11034,7 @@ main()
 - **`type`**: Must be `"KEY_TYPE_ECDSA_EVM"` (currently the only supported authentication method)
 - **Multiple keys**: You can include multiple authorized addresses in the array
 
-When an HTTP request is made to your workflow's endpoint, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
+When an HTTP request is made to trigger your workflow, CRE verifies that the request was signed by a private key corresponding to one of the authorized addresses.
 
 ## Callback and payload
 
@@ -11070,12 +11079,11 @@ The HTTP trigger allows external systems to initiate your workflow execution by
 
 When you deploy a workflow with an HTTP trigger:
 
-1. **Your workflow receives a unique endpoint** managed by the CRE gateway
-2. **External systems send HTTP requests** with JSON payloads to this endpoint
-3. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address
+1. **External systems send HTTP POST requests** to a CRE gateway
+2. **The request specifies your workflow ID** in the JSON-RPC body along with the input payload
+3. **Requests must be cryptographically signed** using a private key corresponding to an authorized EVM address in the target workflow
 4. **CRE validates the signature** against your configured `authorizedKeys`
 5. **If authorized**, your workflow callback executes with the request payload
-6. **Your callback's return value** becomes the HTTP response sent back to the requester
 
 <Aside type="note" title="Security by design">
   For **deployed workflows**, HTTP triggers use cryptographic signatures to ensure only authorized addresses can execute
@@ -11090,7 +11098,7 @@ HTTP triggers are ideal for:
 - **Webhook integration**: Receive events from external services (GitHub, payment processors, etc.)
 - **On-demand execution**: Allow users or systems to trigger specific workflow logic when needed
 - **API gateway patterns**: Create authenticated endpoints that execute blockchain operations
-- **Event bridging**: Connect web2 events to web3 workflows
+- **Event bridging**: Connect offchain systems events to workflows
 
 ## The complete HTTP trigger journey