various updates to SDK reference and examples (#3307)

Author: khadni

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

@@ -44,7 +44,7 @@ func onHttpTrigger(config *Config, runtime cre.Runtime, payload *http.Payload) (
     logger := runtime.Logger()
 
     // Unmarshal the JSON input from bytes
-    var requestData map[string]interface{}
+    var requestData map[string]any
     if err := json.Unmarshal(payload.Input, &requestData); err != nil {
         return nil, fmt.Errorf("failed to unmarshal input: %w", err)
     }
@@ -92,7 +92,7 @@ func onHttpTrigger(config *Config, runtime cre.Runtime, payload *http.Payload) (
 
     // The payload.Input is []byte containing JSON data.
     // Unmarshal it into a map or a custom struct.
-    var requestData map[string]interface{}
+    var requestData map[string]any
     if err := json.Unmarshal(payload.Input, &requestData); err != nil {
         return nil, fmt.Errorf("failed to unmarshal input: %w", err)
     }

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

@@ -4174,7 +4174,7 @@ By default, `cre workflow simulate` performs a dry run without broadcasting tran
 cre workflow simulate my-workflow --broadcast --target staging-settings
 ```
 
-See the [CLI Reference](/cre/reference/cli#cre-workflow-simulate) for more details.
+See the [CLI Reference](/cre/reference/cli/workflow#cre-workflow-simulate) for more details.
 
 ## Troubleshooting
 
@@ -9758,7 +9758,7 @@ go mod tidy
 <Aside type="note" title="Funding Your Account">
   This step submits an onchain transaction, which requires gas. Before running the simulation, verify that the account
   associated with the private key from [Part
-  1](/cre/getting-started/part-1-project-setup#step-3-configure-the-environment) is funded with sufficient Sepolia ETH.
+  1](/cre/getting-started/part-1-project-setup-go#set-up-your-private-key) is funded with sufficient Sepolia ETH.
   An unfunded account will cause the transaction to fail, often with an error message like `gas required exceeds
     allowance`.
 
@@ -10758,7 +10758,7 @@ The `http.Client` is the SDK's interface for the underlying [HTTP Capability](/c
 All HTTP requests are wrapped in a consensus mechanism to provide a single, reliable result. The SDK provides two ways to do this:
 
 - **[`http.SendRequest`](#1-the-httpsendrequest-pattern-recommended):** (Recommended) A high-level helper function that simplifies making requests.
-- **[`cre.RunInNodeMode`](#2-the-cre-runinnodemode-pattern-low-level):** The lower-level pattern for more complex scenarios.
+- **[`cre.RunInNodeMode`](#2-the-creruninnodemode-pattern-low-level):** The lower-level pattern for more complex scenarios.
 
 ## Prerequisites
 
@@ -11640,7 +11640,7 @@ Here are common patterns for formatting reports. Choose the one that matches you
 | Pattern                                                                                                 | When to use                                               |
 | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
 | [**Pattern 1: Report in body**](#pattern-1-report-in-body-simplest)                                     | Your API accepts raw binary data and handles decoding     |
-| [**Pattern 2: Report + signatures in body**](#pattern-2-report-signatures-in-body)                      | Your API needs everything concatenated in one binary blob |
+| [**Pattern 2: Report + signatures in body**](#pattern-2-report--signatures-in-body)                     | Your API needs everything concatenated in one binary blob |
 | [**Pattern 3: Report in body, signatures in headers**](#pattern-3-report-in-body-signatures-in-headers) | Your API needs signatures separated for easier parsing    |
 | [**Pattern 4: JSON-formatted report**](#pattern-4-json-formatted-report)                                | Your API only accepts JSON payloads                       |
 
@@ -12663,7 +12663,7 @@ func onHttpTrigger(config *Config, runtime cre.Runtime, payload *http.Payload) (
     logger := runtime.Logger()
 
     // Unmarshal the JSON input from bytes
-    var requestData map[string]interface{}
+    var requestData map[string]any
     if err := json.Unmarshal(payload.Input, &requestData); err != nil {
         return nil, fmt.Errorf("failed to unmarshal input: %w", err)
     }
@@ -12711,7 +12711,7 @@ func onHttpTrigger(config *Config, runtime cre.Runtime, payload *http.Payload) (
 
     // The payload.Input is []byte containing JSON data.
     // Unmarshal it into a map or a custom struct.
-    var requestData map[string]interface{}
+    var requestData map[string]any
     if err := json.Unmarshal(payload.Input, &requestData); err != nil {
         return nil, fmt.Errorf("failed to unmarshal input: %w", err)
     }
@@ -13211,8 +13211,8 @@ This is a generic interface passed as the final argument to `cre.RunInNodeMode`.
 
 There are two primary ways to specify an aggregation method:
 
-1. [**Using Built-in Functions**](/cre/reference/sdk/consensus-go/#1-built-in-aggregation-functions): For simple types, you can use functions like [`ConsensusMedianAggregation`](/cre/reference/sdk/consensus/#consensusmedianaggregationt).
-2. [**Using Struct Tags**](/cre/reference/sdk/consensus-go/#2-aggregation-via-struct-tags): For complex types (structs), you can use [`ConsensusAggregationFromTags`](/cre/reference/sdk/consensus/#aggregation-via-struct-tags).
+1. [**Using Built-in Functions**](/cre/reference/sdk/consensus-go/#1-built-in-aggregation-functions): For simple types, you can use functions like [`ConsensusMedianAggregation`](/cre/reference/sdk/consensus-go#consensusmedianaggregationt).
+2. [**Using Struct Tags**](/cre/reference/sdk/consensus-go/#2-aggregation-via-struct-tags): For complex types (structs), you can use [`ConsensusAggregationFromTags`](/cre/reference/sdk/consensus-go#2-aggregation-via-struct-tags).
 
 ## 1. Built-in aggregation functions
 
@@ -13368,7 +13368,7 @@ These interfaces provide access to capabilities and manage the execution context
 
 - **`cre.Runtime` ("Easy Mode")**: Passed to your main trigger callback, this represents the **DON's (Decentralized Oracle Network) execution context**. It is used for operations that are already guaranteed to be Byzantine Fault Tolerant (BFT). When you use the `Runtime`, you ask the network to execute something, and CRE handles the underlying complexity to ensure you get back one final, secure, and trustworthy result. A common use case is writing a transaction to a blockchain with the EVM client.
 
-- **`cre.NodeRuntime` ("Manual Mode")**: Represents an **individual node's execution context**. This is used when a BFT guarantee cannot be provided automatically (e.g., calling a third-party API). You tell each node to perform a task on its own, and each node returns its own individual answer. You are then responsible for telling the SDK how to combine them into a single, trusted result by providing a consensus and aggregation algorithm. It is used exclusively inside a [`RunInNodeMode`](#sdkruninnodemode) block and is provided by that function—you do not get this type directly in your handler's callback.
+- **`cre.NodeRuntime` ("Manual Mode")**: Represents an **individual node's execution context**. This is used when a BFT guarantee cannot be provided automatically (e.g., calling a third-party API). You tell each node to perform a task on its own, and each node returns its own individual answer. You are then responsible for telling the SDK how to combine them into a single, trusted result by providing a consensus and aggregation algorithm. It is used exclusively inside a [`RunInNodeMode`](#creruninnodemode) block and is provided by that function—you do not get this type directly in your handler's callback.
 
 To learn more about how to aggregate results from `NodeRuntime`, see the [Consensus & Aggregation](/cre/reference/sdk/consensus) reference.
 
@@ -14638,7 +14638,7 @@ Now you are ready to compile and run the workflow. The workflow code (`workflow.
    <Aside type="note" title="Onchain Writes are Dry Runs by Default">
      The `--broadcast` flag is included here because this workflow performs an onchain write. By default, the `simulate`
      command performs a dry run and will not broadcast the transaction without this flag. For more details, see the `cre
-       workflow simulate` [reference](/cre/reference/cli#cre-workflow-simulate).
+       workflow simulate` [reference](/cre/reference/cli/workflow#cre-workflow-simulate).
    </Aside>
 
    You will first see a `Workflow compiled` message, followed by the trigger selection menu.

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

@@ -8550,7 +8550,7 @@ main()
 <Aside type="note" title="Funding Your Account">
   This step submits an onchain transaction, which requires gas. Before running the simulation, verify that the account
   associated with the private key from [Part
-  1](/cre/getting-started/part-1-project-setup#step-3-configure-your-workflow) is funded with sufficient Sepolia ETH.
+  1](/cre/getting-started/part-1-project-setup-ts#set-up-your-private-key) is funded with sufficient Sepolia ETH.
   An unfunded account will cause the transaction to fail, often with an error message like `gas required exceeds
     allowance`.
 
@@ -10444,7 +10444,7 @@ Here are common patterns for formatting reports. Choose the one that matches you
 | Pattern                                                                                                 | When to use                                               |
 | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
 | [**Pattern 1: Report in body**](#pattern-1-report-in-body-simplest)                                     | Your API accepts raw binary data and handles decoding     |
-| [**Pattern 2: Report + signatures in body**](#pattern-2-report-signatures-in-body)                      | Your API needs everything concatenated in one binary blob |
+| [**Pattern 2: Report + signatures in body**](#pattern-2-report--signatures-in-body)                     | Your API needs everything concatenated in one binary blob |
 | [**Pattern 3: Report in body, signatures in headers**](#pattern-3-report-in-body-signatures-in-headers) | Your API needs signatures separated for easier parsing    |
 | [**Pattern 4: JSON-formatted report**](#pattern-4-json-formatted-report)                                | Your API only accepts JSON payloads                       |
 
@@ -12077,7 +12077,7 @@ This is a generic type passed as the second argument to `runtime.runInNodeMode()
 There are two primary ways to specify an aggregation method:
 
 1. [**Using built-in functions**](/cre/reference/sdk/consensus-ts#1-built-in-aggregation-functions): For simple types, use functions like [`consensusMedianAggregation()`](#consensusmedianaggregationt).
-2. [**Using field-based aggregation**](/cre/reference/sdk/consensus-ts#2-field-based-aggregation-for-objects): For complex types (objects), use [`ConsensusAggregationByFields()`](#consensusaggregationbyfields).
+2. [**Using field-based aggregation**](/cre/reference/sdk/consensus-ts#2-field-based-aggregation-for-objects): For complex types (objects), use [`ConsensusAggregationByFields()`](#consensusaggregationbyfieldstfields).
 
 ## 1. Built-in aggregation functions
 
@@ -13213,6 +13213,86 @@ function hexToBase64(hex: Hex): string
 
 ***
 
+### `protoBigIntToBigint()`
+
+Converts a protobuf `BigInt` (returned by SDK methods like `headerByNumber`) to a native JavaScript `bigint`. Use this when you need to perform arithmetic on block numbers or other numeric values returned from the blockchain.
+
+**Signature:**
+
+```typescript
+function protoBigIntToBigint(pb: ProtoBigInt): bigint
+```
+
+**Parameters:**
+
+- `pb`: A protobuf `BigInt` object with `absVal` (Uint8Array) and `sign` (bigint) fields
+
+**Returns:**
+
+A native JavaScript `bigint` value.
+
+**Usage:**
+
+```typescript
+import { protoBigIntToBigint } from "@chainlink/cre-sdk"
+
+// Get the latest block number from the blockchain
+const latestHeader = evmClient.headerByNumber(runtime, {}).result()
+
+// Convert the protobuf BigInt to a native bigint for arithmetic
+const latestBlockNum = protoBigIntToBigint(latestHeader.header.blockNumber)
+const customBlock = latestBlockNum - 500n // Now you can do arithmetic
+
+console.log(`Latest block: ${latestBlockNum}`)
+console.log(`Custom block (500 blocks ago): ${customBlock}`)
+```
+
+See [Custom Block Depths](/cre/guides/workflow/using-evm-client/onchain-read-ts#custom-block-depths) for a complete example.
+
+***
+
+### `blockNumber()`
+
+Converts a native `bigint`, `number`, or `string` to the protobuf `BigInt` JSON format required by SDK methods. This is a convenience alias for `bigintToProtoBigInt`. Use this when specifying an explicit block height for contract calls or other blockchain queries.
+
+**Signature:**
+
+```typescript
+function blockNumber(n: number | bigint | string): BigIntJson
+```
+
+**Parameters:**
+
+- `n`: The block number as a native `bigint`, `number`, or `string`
+
+**Returns:**
+
+A `BigIntJson` object in the protobuf format expected by SDK methods.
+
+**Usage:**
+
+```typescript
+import { blockNumber, encodeCallMsg } from "@chainlink/cre-sdk"
+import { zeroAddress } from "viem"
+
+// Read from a specific historical block
+const historicalBlock = 9767655n
+const contractCall = evmClient
+  .callContract(runtime, {
+    call: encodeCallMsg({
+      from: zeroAddress,
+      to: contractAddress,
+      data: callData,
+    }),
+    blockNumber: blockNumber(historicalBlock),
+  })
+  .result()
+```
+
+See [Custom Block Depths](/cre/guides/workflow/using-evm-client/onchain-read-ts#custom-block-depths) for a complete example.
+
+***
+
 ### `prepareReportRequest()`
 
 Prepares a report request with default EVM encoding parameters for use with `runtime.report()`. This helper simplifies report generation by automatically setting the standard encoding configuration (`evm`, `ecdsa`, `keccak256`) required for EVM-based workflows.
@@ -14039,8 +14119,8 @@ const reserveInfo = httpClient
 Source: https://docs.chain.link/cre/reference/sdk/overview-ts
 Last Updated: 2025-11-04
 
-<Aside type="note" title="Required SDK Version: v1.0.0">
-  The CRE CLI automatically includes version `v1.0.0` of the `@chainlink/cre-sdk` package when you initialize a new
+<Aside type="note" title="Required SDK Version: v1.0.1">
+  The CRE CLI automatically includes version `v1.0.1` of the `@chainlink/cre-sdk` package when you initialize a new
   TypeScript workflow with `cre init`.
 </Aside>
 
@@ -14845,7 +14925,7 @@ Now you are ready to compile and run the workflow. The single `main.ts` file you
    <Aside type="note" title="Onchain Writes are Dry Runs by Default">
      The `--broadcast` flag is included here because this workflow performs an onchain write. By default, the `simulate`
      command performs a dry run and will not broadcast the transaction without this flag. For more details, see the `cre
-       workflow simulate` [reference](/cre/reference/cli#cre-workflow-simulate).
+       workflow simulate` [reference](/cre/reference/cli/workflow#cre-workflow-simulate).
    </Aside>
 
    You will first see a `Workflow compiled` message, followed by the trigger selection menu.

src/content/cre/reference/sdk/evm-client-ts.mdx

@@ -559,6 +559,86 @@ function hexToBase64(hex: Hex): string
 
 ---
 
+### `protoBigIntToBigint()`
+
+Converts a protobuf `BigInt` (returned by SDK methods like `headerByNumber`) to a native JavaScript `bigint`. Use this when you need to perform arithmetic on block numbers or other numeric values returned from the blockchain.
+
+**Signature:**
+
+```typescript
+function protoBigIntToBigint(pb: ProtoBigInt): bigint
+```
+
+**Parameters:**
+
+- `pb`: A protobuf `BigInt` object with `absVal` (Uint8Array) and `sign` (bigint) fields
+
+**Returns:**
+
+A native JavaScript `bigint` value.
+
+**Usage:**
+
+```typescript
+import { protoBigIntToBigint } from "@chainlink/cre-sdk"
+
+// Get the latest block number from the blockchain
+const latestHeader = evmClient.headerByNumber(runtime, {}).result()
+
+// Convert the protobuf BigInt to a native bigint for arithmetic
+const latestBlockNum = protoBigIntToBigint(latestHeader.header.blockNumber)
+const customBlock = latestBlockNum - 500n // Now you can do arithmetic
+
+console.log(`Latest block: ${latestBlockNum}`)
+console.log(`Custom block (500 blocks ago): ${customBlock}`)
+```
+
+See [Custom Block Depths](/cre/guides/workflow/using-evm-client/onchain-read-ts#custom-block-depths) for a complete example.
+
+---
+
+### `blockNumber()`
+
+Converts a native `bigint`, `number`, or `string` to the protobuf `BigInt` JSON format required by SDK methods. This is a convenience alias for `bigintToProtoBigInt`. Use this when specifying an explicit block height for contract calls or other blockchain queries.
+
+**Signature:**
+
+```typescript
+function blockNumber(n: number | bigint | string): BigIntJson
+```
+
+**Parameters:**
+
+- `n`: The block number as a native `bigint`, `number`, or `string`
+
+**Returns:**
+
+A `BigIntJson` object in the protobuf format expected by SDK methods.
+
+**Usage:**
+
+```typescript
+import { blockNumber, encodeCallMsg } from "@chainlink/cre-sdk"
+import { zeroAddress } from "viem"
+
+// Read from a specific historical block
+const historicalBlock = 9767655n
+const contractCall = evmClient
+  .callContract(runtime, {
+    call: encodeCallMsg({
+      from: zeroAddress,
+      to: contractAddress,
+      data: callData,
+    }),
+    blockNumber: blockNumber(historicalBlock),
+  })
+  .result()
+```
+
+See [Custom Block Depths](/cre/guides/workflow/using-evm-client/onchain-read-ts#custom-block-depths) for a complete example.
+
+---
+
 ### `prepareReportRequest()`
 
 Prepares a report request with default EVM encoding parameters for use with `runtime.report()`. This helper simplifies report generation by automatically setting the standard encoding configuration (`evm`, `ecdsa`, `keccak256`) required for EVM-based workflows.

src/content/cre/reference/sdk/overview-ts.mdx

@@ -12,8 +12,8 @@ metadata:
 
 import { Aside } from "@components"
 
-<Aside type="note" title="Required SDK Version: v1.0.0">
-  The CRE CLI automatically includes version `v1.0.0` of the `@chainlink/cre-sdk` package when you initialize a new
+<Aside type="note" title="Required SDK Version: v1.0.1">
+  The CRE CLI automatically includes version `v1.0.1` of the `@chainlink/cre-sdk` package when you initialize a new
   TypeScript workflow with `cre init`.
 </Aside>
 

src/content/data-feeds/llms-full.txt

@@ -4151,7 +4151,7 @@ starkli --version
 0.2.8 (f59724e)
 ```
 
-Follow the official [installation guide]((https://book.starkli.rs/installation)) if necessary.
+Follow the official [installation guide](https://book.starkli.rs/installation) if necessary.
 
 ### Read data from a Chainlink Price Feed