### Start Inspectr in Basic Proxy Mode

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Demonstrates how to start Inspectr as a basic HTTP proxy. It forwards traffic to a specified backend service and captures requests/responses for real-time inspection in the console and UI.

```bash
# Start Inspectr proxy forwarding to your backend service
./inspectr --listen=":8080" --backend="http://localhost:3000"

# Make requests through the proxy
curl http://localhost:8080/api/users

# POST request with JSON body
curl -X POST http://localhost:8080/api/users \
  -H "Content-Type: application/json" \
  -d '{"name": "John Doe", "email": "john@example.com"}'

# View captured requests in the UI at http://localhost:4004
```

--------------------------------

### Install Inspectr via NPM

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Instructions for installing Inspectr globally using NPM or running it directly with npx. This allows for immediate use without a full installation.

```bash
npm install -g @inspectr/inspectr

npx @inspectr/inspectr --backend=http://localhost:3000
```

--------------------------------

### Example .inspectr.yaml Configuration

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

This snippet demonstrates a standard configuration file for Inspectr. It defines the listening port, backend forwarding address, and UI application settings.

```yaml
listen: ":8080" # Port where Inspectr listens 
backend: "http://localhost:3000"  # Backend to forward requests
print: true  # Log requests in console
app: true  # Start UI App
appPort: "9999" # Configure a custom Port for App
```

--------------------------------

### Install Inspectr via Homebrew

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Steps to install Inspectr on macOS using the Homebrew package manager. This involves tapping the Inspectr repository and then installing the Inspectr package.

```bash
brew tap inspectr-hq/inspectr
brew install inspectr
```

--------------------------------

### Configure Inspectr via YAML File

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Define Inspectr configuration settings in a .inspectr.yaml file for persistent setup.

```yaml
listen: ":8080"
backend: "http://localhost:3000"
expose: true
channel: "your-channel-abc"
```

--------------------------------

### Configure Inspectr via Command Line

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Start the Inspectr proxy using command-line arguments to define the listening port, backend service, and public exposure settings.

```bash
./inspectr --listen=":8080" --backend="http://localhost:3000" --expose --channel="your-channel-abc"
```

--------------------------------

### Launch Inspectr Proxy

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Starts the Inspectr proxy server using npx, pointing to a local backend service. This command initializes the proxy to listen for incoming requests and forward them to the specified backend.

```bash
npx @inspectr/inspectr --backend=http://localhost:3000
```

--------------------------------

### Configure Inspectr Proxy for Front-End Requests

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Demonstrates how to redirect front-end API calls to an Inspectr proxy instance and how to start the proxy server via CLI.

```javascript
fetch("http://localhost:8080/data", {
  method: "GET",
  headers: {
    "Authorization": "Bearer token",
    "Content-Type": "application/json"
  }
});
```

```bash
./inspectr --listen=":8080" --backend="https://api.example.com"
./inspectr --listen=":8080" --backend="https://api.example.com" --expose=true
```

--------------------------------

### Inspectr Basic Usage

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Example of how to run Inspectr to forward traffic to a backend service and view captured traffic.

```APIDOC
## Basic Usage Example

Configure Inspectr to forward to the actual API:
```bash
./inspectr --listen=":8080" --backend="https://api.example.com"
```

All requests to `localhost:8080` are captured and forwarded.
View traffic in real-time at `http://localhost:4004`.
```

--------------------------------

### Inspect Webhook Events

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Start Inspectr in catch mode to capture incoming webhooks without a backend, returning a 200 OK response automatically.

```bash
./inspectr --listen=":8080" --catch=true --expose=true
```

--------------------------------

### Start Inspectr in Mock Backend Mode

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Explains how to configure Inspectr to simulate API responses using an OpenAPI specification file. This is beneficial for frontend development when the backend API is unavailable, allowing for testing against mocked data.

```bash
# Start Inspectr with mock backend
./inspectr --listen=":8080" --mock-backend="./openapi.yaml"

# Make requests - responses are generated from OpenAPI examples
curl http://localhost:8080/api/pets

# POST request to mocked endpoint
curl -X POST http://localhost:8080/api/pets \
  -H "Content-Type: application/json" \
  -d '{"name": "Fluffy", "tag": "cat"}'

# Combine mock mode with public exposure
./inspectr --listen=":8080" --mock-backend="./openapi.yaml" --expose
```

--------------------------------

### Enable API Key Authentication with Inspectr

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This section demonstrates how to start Inspectr with API key authentication enabled to protect proxied services. It shows the command-line arguments for enabling auth, setting a secret key, and how to make authenticated requests using either the secret key or a generated JWT token. Unauthenticated requests will result in a 401 Unauthorized response.

```bash
# Start Inspectr with authentication enabled
./inspectr --listen=":8080" --backend="http://localhost:3000" \
  --auth-enabled=true --auth-secret="mysecretkey"

# Inspectr outputs authentication headers:
# inspectr-auth-key: mysecretkey
# inspectr-auth-token: <generated-jwt>

# Make authenticated requests using the secret key
curl http://localhost:8080/api/protected \
  -H "inspectr-auth-key: mysecretkey"

# Or use JWT token authentication
curl http://localhost:8080/api/protected \
  -H "inspectr-auth-token: eyJhbGciOiJIUzI1NiIs..."

# Unauthenticated requests receive 401 Unauthorized
curl http://localhost:8080/api/protected
# Response: 401 Unauthorized
```

--------------------------------

### Configure Inspectr with YAML File

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This section explains how to configure Inspectr using a `.inspectr.yaml` file, providing an alternative to command-line flags. It shows an example YAML configuration for various settings including listen address, backend, and authentication. It also demonstrates how to run Inspectr with the configuration file, either automatically detected or specified via a command-line argument. Command-line arguments will override settings in the YAML file.

```yaml
# .inspectr.yaml
listen: ":8080"
backend: "http://localhost:3000"
print: true
app: true
appPort: "4004"
expose: true
channel: "my-dev-api"
channelCode: "secret123"

# Authentication settings
auth-enabled: false
auth-secret: ""

# Mock backend (mutually exclusive with backend)
# mockBackend: "./openapi.yaml"
```

```bash
# Run with config file (auto-detected if named .inspectr.yaml)
./inspectr

# Or specify config file path
./inspectr --config="./my-config.yaml"
```

--------------------------------

### YAML Configuration File

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Configure Inspectr using a `.inspectr.yaml` file as an alternative to command-line flags. Command-line arguments take precedence over settings in the YAML file. This section provides an example of a configuration file and how to run Inspectr with it.

```APIDOC
## YAML Configuration File

Configure Inspectr using a `.inspectr.yaml` file instead of command-line flags. Command-line arguments override YAML settings.

### Example `.inspectr.yaml`

```yaml
# .inspectr.yaml
listen: ":8080"
backend: "http://localhost:3000"
print: true
app: true
appPort: "4004"
expose: true
channel: "my-dev-api"
channelCode: "secret123"

# Authentication settings
auth-enabled: false
auth-secret: ""

# Mock backend (mutually exclusive with backend)
# mockBackend: "./openapi.yaml"
```

### Running Inspectr with Configuration

**Auto-detection (if file is named `.inspectr.yaml`):**

```bash
./inspectr
```

**Specifying config file path:**

```bash
./inspectr --config="./my-config.yaml"
```
```

--------------------------------

### Start Inspectr in Webhook Capture Mode

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Shows how to run Inspectr in webhook capture mode. In this mode, Inspectr accepts incoming requests (e.g., from webhooks) and returns a 200 OK response without needing a backend service, while still capturing the payload.

```bash
# Start Inspectr in catch mode (no backend needed)
./inspectr --listen=":8080" --catch=true

# Simulate a webhook event
curl -X POST http://localhost:8080/webhook/stripe \
  -H "Content-Type: application/json" \
  -H "Stripe-Signature: t=1234567890,v1=signature" \
  -d '{
    "id": "evt_1234567890",
    "type": "payment_intent.succeeded",
    "data": {
      "object": {
        "id": "pi_1234567890",
        "amount": 2000,
        "currency": "usd",
        "status": "succeeded"
      }
    }
  }'

# Response: 200 OK (webhook payload captured and displayed in UI)
```

--------------------------------

### Inspect API HTTP Traffic

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Start Inspectr to proxy traffic to a local backend service on port 3000 while logging to the console and UI.

```bash
./inspectr --listen=":8080" --backend="http://localhost:3000"
```

--------------------------------

### Frontend Integration with Inspectr Proxy

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This snippet demonstrates how to integrate Inspectr into frontend applications by routing API calls through the Inspectr proxy. It shows an example of an original API call using `fetch` and how to modify it to send the request to Inspectr instead, ensuring that headers like `Authorization` are preserved. This allows Inspectr to capture and potentially modify requests before they reach the backend.

```javascript
// Original API call
fetch("https://api.example.com/data", {
  method: "GET",
  headers: {
    "Authorization": "Bearer token",
    "Content-Type": "application/json"
  }
});

// Route through Inspectr proxy
fetch("http://localhost:8080/data", {
  method: "GET",
  headers: {
    "Authorization": "Bearer token",
    "Content-Type": "application/json"
  }
});
```

--------------------------------

### Inspectr HTTP Request Schema Example (JSON)

Source: https://github.com/inspectr-hq/inspectr/blob/main/schema/inspectr-schema-http-operation.md

This JSON object represents the structure for capturing incoming HTTP request details within Inspectr. It includes method, URL, headers, body, and client information.

```json
{
  "method": "POST",
  "url": "http://localhost:3000/api/users?sort=asc",
  "server": "localhost:3000",
  "path": "/api/users",
  "client_ip": "192.168.1.100",
  "http_version": "HTTP/1.1",
  "headers": [
    { "name": "User-Agent", "value": "MyBrowser/1.0" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "headers_size": 350,
  "query_params":  [
    { "name": "sort", "value": "asc" }
  ],
  "cookies": [],
  "body": "{\"name\":\"Marco Polo\",\"email\":\"marco@polo-ventures.com\"}",
  "body_size": 70,
  "timestamp": "2025-02-14T15:00:00.120Z"
}
```

--------------------------------

### Simulate API Responses with Inspectr Headers (Bash)

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

This example demonstrates how to use curl with custom headers to simulate different API response scenarios like delays, status codes, and content types. These headers are used in Inspectr's mock and catch modes to override default responses.

```bash
curl -X GET http://localhost:8080/api/items \
-H "inspectr-response-status: 503" \
-H "inspectr-response-delay: 2000" \
-H "inspectr-response-content-type: application/json" \
-H "inspectr-response-example: errorExample"
```

--------------------------------

### Access Authentication Guard

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This section details how to enable and use API key authentication with Inspectr to protect proxied services. It shows how to start Inspectr with authentication enabled, the headers Inspectr outputs, and how to make authenticated requests using either the secret key or a JWT token. Unauthenticated requests will result in a 401 Unauthorized response.

```APIDOC
## Access Authentication Guard

Protect proxied services with API key authentication when your backend doesn't include its own auth layer.

### Starting Inspectr with Authentication

```bash
# Start Inspectr with authentication enabled
./inspectr --listen=":8080" --backend="http://localhost:3000" \
  --auth-enabled=true --auth-secret="mysecretkey"
```

### Inspectr Output Headers

Inspectr outputs the following authentication headers:

```
inspectr-auth-key: mysecretkey
inspectr-auth-token: <generated-jwt>
```

### Making Authenticated Requests

**Using Secret Key:**

```bash
curl http://localhost:8080/api/protected \
  -H "inspectr-auth-key: mysecretkey"
```

**Using JWT Token:**

```bash
curl http://localhost:8080/api/protected \
  -H "inspectr-auth-token: eyJhbGciOiJIUzI1NiIs..."
```

### Unauthenticated Requests

Unauthenticated requests receive a `401 Unauthorized` response.

```bash
curl http://localhost:8080/api/protected
# Response: 401 Unauthorized
```
```

--------------------------------

### Inspectr HTTP Response Schema Example (JSON)

Source: https://github.com/inspectr-hq/inspectr/blob/main/schema/inspectr-schema-http-operation.md

This JSON object defines the structure for capturing HTTP response details in Inspectr. It includes status codes, headers, body content, and timestamps.

```json
{
  "status": 201,
  "status_text": "Created",
  "http_version": "HTTP/1.1",
  "headers": [
    { "name": "Content-Type", "value": "application/json" },
    { "name": "Server", "value": "ExampleServer/1.0" }
  ],
  "headers_size": 220,
  "cookies": [],
  "body": "{\"success\":true,\"id\":123}",
  "body_size": 75,
  "timestamp": "2025-02-14T15:01:00.120Z"
}
```

--------------------------------

### Control Responses with Inspectr Override Headers

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Details how to use special headers with Inspectr to control proxy responses. This allows simulating various scenarios such as delays, specific HTTP status codes, content types, and predefined OpenAPI examples.

```bash
# Simulate a 2-second delay
curl http://localhost:8080/api/items \
  -H "inspectr-response-delay: 2000"

# Override status code to simulate server error
curl http://localhost:8080/api/items \
  -H "inspectr-response-status: 503"

# Combine multiple overrides
curl -X GET http://localhost:8080/api/items \
  -H "inspectr-response-status: 503" \
  -H "inspectr-response-delay: 2000" \
  -H "inspectr-response-content-type: application/json" \
  -H "inspectr-response-example: errorExample"

# Force specific OpenAPI example in mock mode
curl http://localhost:8080/api/pets \
  -H "inspectr-response-example: notFoundExample"
```

--------------------------------

### CloudEvents Wrapper Format for Inspectr Operations

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This section illustrates how Inspectr wraps captured HTTP operations within the CloudEvents format. This enables standardized event streaming, particularly useful for real-time processing via SSE. The example shows the structure of a CloudEvent, including metadata like `specversion`, `id`, `type`, `source`, and the `data` payload which contains the detailed HTTP operation information.

```json
{
  "specversion": "1.0",
  "id": "36851845-66ac-418e-a7b7-03bd9ab89b99",
  "type": "dev.inspectr.operation.http.v1.completed",
  "time": "2025-02-14T17:57:35.436Z",
  "source": "//ingress.inspectr.dev/my-channel",
  "channel": "my-channel",
  "operation_id": "1234567",
  "datacontenttype": "application/json",
  "data": {
    "version": "1.0",
    "operation_id": "1234567",
    "correlation_id": "xyz-7890",
    "request": { "...request details..." },
    "response": { "...response details..." },
    "timing": { "...timing info..." },
    "meta": {
      "proxy_instance": "inspectr-proxy-1",
      "ingress": {
        "headers": [
          { "name": "Cf-Ipcountry", "value": "US" },
          { "name": "X-Forwarded-Port", "value": "443" }
        ]
      }
    }
  }
}
```

--------------------------------

### Launch Inspectr in Mock Mode

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Explains how to use an OpenAPI specification file to generate mock API responses, useful for testing when the backend is unavailable.

```bash
./inspectr --listen=":8080" --mock-backend="./openapi.yaml"
./inspectr --listen=":8080" --mock-backend="./openapi.yaml" --expose=true
```

--------------------------------

### Inspectr Command-Line Options

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Reference for all available command-line flags to configure Inspectr's behavior.

```APIDOC
## Command-Line Options Reference

| Flag | Type | Default | Description |
|------|------|---------|-------------|
| `--listen` | string | `:8080` | Address/port for incoming HTTP requests |
| `--backend` | string | (empty) | Backend service address to forward requests |
| `--mock-backend` | string | (empty) | OpenAPI spec file path for mock mode |
| `--catch` | boolean | `true` | Return 200 OK if no backend configured |
| `--expose` | boolean | `false` | Enable public tunnel via Inspectr Ingress |
| `--channel` | string | (auto) | Custom subdomain for Inspectr Ingress |
| `--channel-code` | string | (auto) | Security code for channel access |
| `--config` | string | `.inspectr.yaml` | Path to YAML configuration file |
| `--auth-enabled` | boolean | `false` | Enable API key authentication |
| `--auth-secret` | string | (none) | Secret for generating API keys |
| `--app` | boolean | `true` | Enable embedded web UI |
| `--app-port` | string | `4004` | Port for the web UI |
| `--print` | boolean | `true` | Log requests to console |
```

--------------------------------

### Configure Inspectr to Forward Requests

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This command configures Inspectr to listen on port 8080 and forward all incoming requests to the specified backend API at https://api.example.com. All traffic is captured and can be viewed in real-time.

```bash
./inspectr --listen=":8080" --backend="https://api.example.com"
```

--------------------------------

### Frontend Integration

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Demonstrates how to integrate Inspectr into frontend applications by routing API calls through the Inspectr proxy. This allows for inspection and potential modification of outgoing requests.

```APIDOC
## Frontend Integration

Integrate Inspectr into frontend applications by routing API calls through the proxy.

### Original API Call

```javascript
// Original API call
fetch("https://api.example.com/data", {
  method: "GET",
  headers: {
    "Authorization": "Bearer token",
    "Content-Type": "application/json"
  }
});
```

### Routing Through Inspectr Proxy

```javascript
// Route through Inspectr proxy
fetch("http://localhost:8080/data", {
  method: "GET",
  headers: {
    "Authorization": "Bearer token",
    "Content-Type": "application/json"
  }
});
```
```

--------------------------------

### Expose Local Service Publicly with Inspectr Ingress

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Demonstrates how to use Inspectr to expose a local service to the public internet via a secure tunnel. This feature assigns a unique public URL that forwards requests to the local server, optionally using custom channels and codes for authentication.

```bash
# Expose local service with auto-generated subdomain
./inspectr --listen=":8080" --backend="http://localhost:3000" --expose

# Expose with custom channel/subdomain
./inspectr --listen=":8080" --backend="http://localhost:3000" \
  --expose --channel="my-api-dev" --channel-code="mysecretcode"

# Your service is now accessible at:
# https://my-api-dev.in-spectr.dev

# Remote clients can now reach your local service
curl https://my-api-dev.in-spectr.dev/api/users
```

--------------------------------

### Run Inspectr via Docker

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Instructions for pulling the latest Inspectr Docker image and running it. This method is useful for containerized environments and ensures consistent execution.

```bash
docker pull ghcr.io/inspectr-hq/inspectr:latest
docker run --rm -p 4004:4004 -p 8080:8080 ghcr.io/inspectr-hq/inspectr:latest
```

--------------------------------

### Inspectr Command-Line Options Reference

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Reference for Inspectr's command-line flags, detailing their purpose, type, and default values. These options control listening address, backend configuration, mock mode, request catching, public exposure, and more.

```bash
# Listen address/port for incoming HTTP requests
# Default: :8080
--listen string

# Backend service address to forward requests
# Default: (empty)
--backend string

# OpenAPI spec file path for mock mode
# Default: (empty)
--mock-backend string

# Return 200 OK if no backend configured
# Default: true
--catch boolean

# Enable public tunnel via Inspectr Ingress
# Default: false
--expose boolean

# Custom subdomain for Inspectr Ingress
# Default: (auto)
--channel string

# Security code for channel access
# Default: (auto)
--channel-code string

# Path to YAML configuration file
# Default: .inspectr.yaml
--config string

# Enable API key authentication
# Default: false
--auth-enabled boolean

# Secret for generating API keys
# Default: (none)
--auth-secret string

# Enable embedded web UI
# Default: true
--app boolean

# Port for the web UI
# Default: 4004
--app-port string

# Log requests to console
# Default: true
--print boolean
```

--------------------------------

### Send Request Through Inspectr

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Demonstrates how to route an HTTP request through the Inspectr proxy using curl. This allows the tool to capture and log the request details for debugging purposes.

```bash
curl http://localhost:8080/
```

--------------------------------

### Verify Traffic with cURL

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Use cURL to send requests to the public Inspectr channel or the local proxy instance to verify traffic capture.

```bash
curl https://your-channel-abc.in-spectr.dev
curl http://localhost:8080
```

--------------------------------

### Metadata

Source: https://github.com/inspectr-hq/inspectr/blob/main/schema/inspectr-schema-http-operation.md

Contains information about the Inspectr proxy instance that handled the request.

```APIDOC
## Metadata (`meta`)

### Description
Contains information about the Inspectr proxy instance that handled the request.

### Properties
#### Request Body
- **proxy_instance** (string) - Required - The Inspectr proxy instance that handled the request.

### Request Example
```json
{
  "proxy_instance": "inspectr-proxy-1"
}
```

### Response
#### Success Response (200)
- **proxy_instance** (string) - The Inspectr proxy instance that handled the request.

#### Response Example
```json
{
  "proxy_instance": "inspectr-proxy-1"
}
```
```

--------------------------------

### API Authentication Headers

Source: https://github.com/inspectr-hq/inspectr/blob/main/README.md

Details on how to authenticate requests to the Inspectr service using required headers.

```APIDOC
## Authentication Headers

### Description
All requests to the Inspectr service require authentication when enabled. You must provide one of the two supported authentication headers.

### Method
N/A

### Endpoint
All API endpoints

### Parameters
#### Request Headers
- **inspectr-auth-key** (string) - Optional - Encrypted secret for quick local testing.
- **inspectr-auth-token** (string) - Optional - JWT signed with the secret; expires per --auth-token-ttl.

### Request Example
curl -H "inspectr-auth-key: mysecret" http://localhost:8080/

### Response
#### Success Response (200)
- **status** (string) - Request successful.

#### Error Response (401)
- **error** (string) - Unauthorized: Missing or invalid authentication credentials.
```

--------------------------------

### Timing Information

Source: https://github.com/inspectr-hq/inspectr/blob/main/schema/inspectr-schema-http-operation.md

Provides details about the timing of a request and its response.

```APIDOC
## Timing Information (`timing`)

### Description
Provides details about the timing of a request and its response.

### Properties
#### Request Body
- **request** (string) - Required - The timestamp when the request was first received.
- **response** (string) - Required - The timestamp when the response was sent back.
- **duration** (integer) - Required - The total time taken from request to response (in milliseconds).

### Request Example
```json
{
  "request": "2025-02-22T12:34:56.789Z",
  "response": "2025-02-22T12:34:56.912Z",
  "duration": 123
}
```

### Response
#### Success Response (200)
- **request** (string) - The timestamp when the request was first received.
- **response** (string) - The timestamp when the response was sent back.
- **duration** (integer) - The total time taken from request to response (in milliseconds).

#### Response Example
```json
{
  "request": "2025-02-22T12:34:56.789Z",
  "response": "2025-02-22T12:34:56.912Z",
  "duration": 123
}
```
```

--------------------------------

### CloudEvents Wrapper Format

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This section describes how Inspectr wraps captured HTTP operations within the CloudEvents format, enabling standardized event streaming for event-driven architectures, particularly via Server-Sent Events (SSE).

```APIDOC
## CloudEvents Wrapper Format

Captured HTTP operations are wrapped in CloudEvents format for event-driven architectures and real-time streaming via SSE.

### CloudEvents Structure Example

```json
{
  "specversion": "1.0",
  "id": "36851845-66ac-418e-a7b7-03bd9ab89b99",
  "type": "dev.inspectr.operation.http.v1.completed",
  "time": "2025-02-14T17:57:35.436Z",
  "source": "//ingress.inspectr.dev/my-channel",
  "channel": "my-channel",
  "operation_id": "1234567",
  "datacontenttype": "application/json",
  "data": {
    "version": "1.0",
    "operation_id": "1234567",
    "correlation_id": "xyz-7890",
    "request": { "...request details..." },
    "response": { "...response details..." },
    "timing": { "...timing info..." },
    "meta": {
      "proxy_instance": "inspectr-proxy-1",
      "ingress": {
        "headers": [
          { "name": "Cf-Ipcountry", "value": "US" },
          { "name": "X-Forwarded-Port", "value": "443" }
        ]
      }
    }
  }
}
```
```

--------------------------------

### Timing Information JSON Structure

Source: https://github.com/inspectr-hq/inspectr/blob/main/schema/inspectr-schema-http-operation.md

Represents the timing object containing request and response timestamps along with the total duration in milliseconds.

```json
{
  "request": "2025-02-22T12:34:56.789Z",
  "response": "2025-02-22T12:34:56.912Z",
  "duration": 123
}
```

--------------------------------

### CloudEvent Types

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Overview of the different CloudEvent types emitted by Inspectr, detailing the event that occurs at each stage of an HTTP operation.

```APIDOC
## CloudEvent Types

| Event Type |
|------------|
| `dev.inspectr.operation.http.v1.received` | Emitted when Inspectr receives an HTTP request |
| `dev.inspectr.operation.http.v1.completed` | Emitted when the full request-response cycle is done |
| `dev.inspectr.operation.http.v1.failed` | Emitted if the request times out or fails |
| `dev.inspectr.operation.http.v1.updated` | Used for modifying or retrying a request |
```

--------------------------------

### Inspectr CloudEvent Schema

Source: https://github.com/inspectr-hq/inspectr/blob/main/schema/inspectr-schema-cloudevents.md

Definition of the Inspectr CloudEvent structure and event lifecycle types.

```APIDOC
## CloudEvent Structure

### Description
Inspectr uses the CloudEvents specification to emit events regarding HTTP request lifecycles. Events follow the pattern: `dev.inspectr.[component].[resource].[version].[action]`.

### Event Types
- `dev.inspectr.operation.http.v1.received`: Emitted when an HTTP request is received.
- `dev.inspectr.operation.http.v1.completed`: Emitted when the request-response cycle is finished.
- `dev.inspectr.operation.http.v1.failed`: Emitted on request failure or timeout.
- `dev.inspectr.operation.http.v1.updated`: Emitted when a request is retried or modified.

### CloudEvent Properties
- **specversion** (string) - Required - CloudEvents specification version (always "1.0").
- **id** (string) - Required - Unique UUID for the event.
- **type** (string) - Required - The event type identifier.
- **time** (string) - Required - ISO 8601 timestamp of emission.
- **source** (string) - Required - Origin of the event (e.g., //ingress.inspectr.dev/TOPIC_NAME).
- **datacontenttype** (string) - Required - Format of the payload (e.g., "application/json").
- **data** (object) - Required - The actual Inspectr HTTP request-response payload.

### Request Example
{
  "specversion": "1.0",
  "id": "a1b2c3d4-e5f6-7890-abcd-1234567890ab",
  "type": "dev.inspectr.operation.http.v1.completed",
  "time": "2023-10-27T10:00:00Z",
  "source": "//ingress.inspectr.dev/my-topic",
  "datacontenttype": "application/json",
  "data": {
    "request_id": "req-123",
    "status": 200
  }
}
```

--------------------------------

### HTTP Operation Data Schema

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

Inspectr captures detailed HTTP operation data, including request and response information, timing, and metadata. This data is structured and can be wrapped in CloudEvents for event streaming.

```APIDOC
## HTTP Operation Data Schema

Inspectr captures HTTP operations in a structured format including request details, response data, timing information, and metadata. The data is wrapped in CloudEvents envelopes for standardized event streaming.

### Data Structure Example

```json
{
  "version": "1.0",
  "operation_id": "1234567",
  "correlation_id": "xyz-7890",
  "request": {
    "method": "POST",
    "url": "http://localhost:3000/api/users?sort=asc",
    "path": "/api/users",
    "server": "localhost:3000",
    "client_ip": "192.168.1.100",
    "http_version": "HTTP/1.1",
    "headers": [
      { "name": "User-Agent", "value": "MyBrowser/1.0" },
      { "name": "Content-Type", "value": "application/json" }
    ],
    "headers_size": 350,
    "query_params": [
      { "name": "sort", "value": "asc" }
    ],
    "cookies": [],
    "body": "{\"name\":\"Marco Polo\",\"email\":\"marco@polo-ventures.com\"}",
    "body_size": 70,
    "timestamp": "2025-02-14T15:00:00.120Z"
  },
  "response": {
    "status": 201,
    "status_text": "Created",
    "http_version": "HTTP/1.1",
    "headers": [
      { "name": "Content-Type", "value": "application/json" },
      { "name": "Server", "value": "ExampleServer/1.0" }
    ],
    "headers_size": 220,
    "cookies": [],
    "body": "{\"success\":true,\"id\":123}",
    "body_size": 75,
    "timestamp": "2025-02-14T15:01:00.120Z"
  },
  "timing": {
    "request": "2025-02-22T12:34:56.789Z",
    "response": "2025-02-22T12:34:56.912Z",
    "duration": 123
  },
  "meta": {
    "proxy_instance": "inspectr-proxy-1"
  }
}
```
```

--------------------------------

### Metadata JSON Structure

Source: https://github.com/inspectr-hq/inspectr/blob/main/schema/inspectr-schema-http-operation.md

Represents the metadata object identifying the specific Inspectr proxy instance that processed the request.

```json
{
  "proxy_instance": "inspectr-proxy-1"
}
```

--------------------------------

### Inspectr HTTP Operation Data Schema

Source: https://context7.com/inspectr-hq/inspectr/llms.txt

This snippet details the structured format Inspectr uses to capture HTTP operations. It includes request and response details, timing information, and metadata, all wrapped within CloudEvents envelopes. The schema outlines fields like method, URL, headers, body, status, and timestamps, providing a comprehensive view of each operation.

```json
{
  "version": "1.0",
  "operation_id": "1234567",
  "correlation_id": "xyz-7890",
  "request": {
    "method": "POST",
    "url": "http://localhost:3000/api/users?sort=asc",
    "path": "/api/users",
    "server": "localhost:3000",
    "client_ip": "192.168.1.100",
    "http_version": "HTTP/1.1",
    "headers": [
      { "name": "User-Agent", "value": "MyBrowser/1.0" },
      { "name": "Content-Type", "value": "application/json" }
    ],
    "headers_size": 350,
    "query_params": [
      { "name": "sort", "value": "asc" }
    ],
    "cookies": [],
    "body": "{\"name\":\"Marco Polo\",\"email\":\"marco@polo-ventures.com\"}",
    "body_size": 70,
    "timestamp": "2025-02-14T15:00:00.120Z"
  },
  "response": {
    "status": 201,
    "status_text": "Created",
    "http_version": "HTTP/1.1",
    "headers": [
      { "name": "Content-Type", "value": "application/json" },
      { "name": "Server", "value": "ExampleServer/1.0" }
    ],
    "headers_size": 220,
    "cookies": [],
    "body": "{\"success\":true,\"id\":123}",
    "body_size": 75,
    "timestamp": "2025-02-14T15:01:00.120Z"
  },
  "timing": {
    "request": "2025-02-22T12:34:56.789Z",
    "response": "2025-02-22T12:34:56.912Z",
    "duration": 123
  },
  "meta": {
    "proxy_instance": "inspectr-proxy-1"
  }
}
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.