@mochabug/adapt-sdk 0.1.1

package/dist/genproto/mochabugapis/adapt/plugins/v1/http_proxy_service_pb.d.ts

@@ -0,0 +1,1282 @@
+import type { GenEnum, GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
+import type { File, FileJson } from "./file_pb";
+import type { Message } from "@bufbuild/protobuf";
+/**
+ * Describes the file mochabugapis/adapt/plugins/v1/http_proxy_service.proto.
+ */
+export declare const file_mochabugapis_adapt_plugins_v1_http_proxy_service: GenFile;
+/**
+ * The http proxy service definition
+ *
+ * This service provides HTTP proxy capabilities with optional TLS configuration
+ * and dynamic header injection for outgoing requests.
+ *
+ * An HTTP proxy configuration must do at least one of the following:
+ * - Configure custom TLS settings (self-signed certs, mTLS, CA pinning)
+ * - Inject dynamic headers using template variables
+ *
+ * If neither TLS nor header injection is configured, the proxy provides no value
+ * and the plugin should use direct HTTP requests instead.
+ *
+ * Example use cases:
+ * - Adding authentication headers to upstream services (Bearer tokens, API keys)
+ * - Injecting custom correlation IDs or tracking headers
+ * - Using mutual TLS (mTLS) for B2B API authentication
+ * - Connecting to services with self-signed certificates
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyDefinition
+ */
+export type HttpProxyDefinition = Message<"mochabugapis.adapt.plugins.v1.HttpProxyDefinition"> & {
+    /**
+     * REQUIRED: Allowed upstream hosts that this proxy can connect to.
+     *
+     * Plugin authors define which external services the plugin will communicate with.
+     * Only publicly accessible hosts are allowed; private IP addresses and non-globally
+     * resolvable hostnames are blocked by the platform.
+     *
+     * ## Transparency & User Visibility
+     *
+     * IMPORTANT: This list is VISIBLE to users during plugin installation and in plugin settings.
+     * Users can see exactly which external endpoints your plugin will connect to.
+     *
+     * Plugin authors MUST be transparent about:
+     * - Which services the plugin connects to
+     * - Why the plugin needs to connect to these hosts
+     * - What data is sent to these endpoints
+     *
+     * Plugins that attempt to hide their network activity or connect to undisclosed endpoints
+     * will be flagged as malicious and removed from the plugin marketplace.
+     *
+     * ## Format
+     *
+     * Each entry must be a valid hostname or publicly routable IP address, optionally with a port:
+     * - "api.example.com" - Exact hostname match
+     * - "*.example.com" - Wildcard subdomain match (matches api.example.com, service.example.com, etc.)
+     * - "api.example.com:8443" - Hostname with specific port
+     * - "*.example.com:8443" - Wildcard subdomain with specific port
+     *
+     * ## Wildcard Rules
+     *
+     * - "*" at the start means "any subdomain" but NOT the root domain
+     *   - "*.example.com" matches "api.example.com" but NOT "example.com"
+     *   - To allow both, add both entries: ["*.example.com", "example.com"]
+     *
+     * - Wildcards only supported at the subdomain level
+     *   - Valid: "*.example.com", "*.api.example.com"
+     *   - Invalid: "api.*.com", "*", "example.*"
+     *
+     * ## Port Matching
+     *
+     * - If no port specified: matches any port on that host
+     *   - "api.example.com" matches api.example.com:80, api.example.com:443, api.example.com:8080
+     *
+     * - If port specified: matches only that specific port
+     *   - "api.example.com:443" matches ONLY api.example.com:443
+     *   - Does NOT match api.example.com:80 or api.example.com:8443
+     *
+     * ## Restrictions
+     *
+     * The following are blocked and will cause validation errors:
+     * - Private IP ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
+     * - Loopback addresses: 127.0.0.0/8, ::1
+     * - Link-local addresses: 169.254.0.0/16, fe80::/10
+     * - Non-globally resolvable hostnames: localhost, *.local, *.internal
+     *
+     * ## Examples
+     *
+     * 1. Single API endpoint:
+     *    allowed_hosts: ["api.example.com"]
+     *
+     * 2. Multiple environments:
+     *    allowed_hosts: ["api.prod.example.com", "api.staging.example.com"]
+     *
+     * 3. All subdomains of a service:
+     *    allowed_hosts: ["*.service.example.com", "service.example.com"]
+     *
+     * 4. Specific port (e.g., non-standard HTTPS):
+     *    allowed_hosts: ["api.example.com:8443"]
+     *
+     * @generated from field: repeated string allowed_hosts = 1;
+     */
+    allowedHosts: string[];
+    /**
+     * Optional TLS configuration for the upstream connection.
+     *
+     * If not specified:
+     * - The protocol (HTTP/HTTPS) is forwarded from the incoming request
+     * - HTTP requests are proxied as HTTP
+     * - HTTPS requests are proxied as HTTPS using the system's default trust store
+     *   (publicly trusted Certificate Authorities like Let's Encrypt, DigiCert, etc.)
+     *
+     * If specified:
+     * - For MODE_SERVER_ONLY: Validates the server certificate against the provided ca_bundle
+     * - For MODE_MTLS: Performs mutual TLS authentication with client certificate
+     *
+     * Use this when:
+     * - Upstream uses self-signed certificates (provide custom ca_bundle)
+     * - Upstream requires mutual TLS (provide client certificate and private key)
+     * - Need to pin specific CA certificates for security
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsDefinition tls = 2;
+     */
+    tls?: TlsDefinition;
+    /**
+     * Dynamic headers to inject into every proxied request using template variables.
+     *
+     * This field is for headers that require DYNAMIC values resolved from template variables.
+     * The caller can always submit static headers directly with each request - this field
+     * is specifically for injecting headers that use variable substitution (e.g., %ACCESS_TOKEN%).
+     *
+     * ## When to Use inject_headers
+     *
+     * Use this field when you need to inject headers with:
+     * - Values that change per request or per user (tokens, session IDs)
+     * - Values that come from user configuration (API keys, tenant IDs)
+     * - Values that need to be kept secret (credentials, tokens)
+     * - Dynamic template substitution using %VARIABLE% syntax
+     *
+     * ## When NOT to Use inject_headers
+     *
+     * Do NOT use this field for:
+     * - Static headers that never change (use direct headers in the request)
+     * - Headers that the caller controls (they can submit these directly)
+     * - Constant values like "Content-Type: application/json"
+     *
+     * The caller can always add, modify, or override headers in their individual requests.
+     * This field is for headers that the plugin definition requires to be injected with
+     * dynamic values before reaching the upstream service.
+     *
+     * ## Header Processing
+     *
+     * The map key is the HTTP header name (e.g., "Authorization", "X-Api-Key").
+     * Header names are case-insensitive per RFC 7230 but will be sent as specified.
+     *
+     * If the same header name appears in both inject_headers and the caller's request:
+     * - The inject_headers value takes precedence (overrides caller's value)
+     * - This ensures plugin-level authentication/configuration is always applied
+     *
+     * ## Common Patterns
+     *
+     * - "Authorization": "Bearer %ACCESS_TOKEN%" - Dynamic OAuth2 token
+     * - "X-Api-Key": "%API_KEY%" - User-provided API key
+     * - "X-Request-ID": "%CORRELATION_ID%" - Tracing identifier
+     * - "X-Tenant-ID": "%TENANT_ID%" - Multi-tenant identifier
+     *
+     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderTemplate> inject_headers = 3;
+     */
+    injectHeaders: {
+        [key: string]: HeaderTemplate;
+    };
+};
+/**
+ * The http proxy service definition
+ *
+ * This service provides HTTP proxy capabilities with optional TLS configuration
+ * and dynamic header injection for outgoing requests.
+ *
+ * An HTTP proxy configuration must do at least one of the following:
+ * - Configure custom TLS settings (self-signed certs, mTLS, CA pinning)
+ * - Inject dynamic headers using template variables
+ *
+ * If neither TLS nor header injection is configured, the proxy provides no value
+ * and the plugin should use direct HTTP requests instead.
+ *
+ * Example use cases:
+ * - Adding authentication headers to upstream services (Bearer tokens, API keys)
+ * - Injecting custom correlation IDs or tracking headers
+ * - Using mutual TLS (mTLS) for B2B API authentication
+ * - Connecting to services with self-signed certificates
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyDefinition
+ */
+export type HttpProxyDefinitionJson = {
+    /**
+     * REQUIRED: Allowed upstream hosts that this proxy can connect to.
+     *
+     * Plugin authors define which external services the plugin will communicate with.
+     * Only publicly accessible hosts are allowed; private IP addresses and non-globally
+     * resolvable hostnames are blocked by the platform.
+     *
+     * ## Transparency & User Visibility
+     *
+     * IMPORTANT: This list is VISIBLE to users during plugin installation and in plugin settings.
+     * Users can see exactly which external endpoints your plugin will connect to.
+     *
+     * Plugin authors MUST be transparent about:
+     * - Which services the plugin connects to
+     * - Why the plugin needs to connect to these hosts
+     * - What data is sent to these endpoints
+     *
+     * Plugins that attempt to hide their network activity or connect to undisclosed endpoints
+     * will be flagged as malicious and removed from the plugin marketplace.
+     *
+     * ## Format
+     *
+     * Each entry must be a valid hostname or publicly routable IP address, optionally with a port:
+     * - "api.example.com" - Exact hostname match
+     * - "*.example.com" - Wildcard subdomain match (matches api.example.com, service.example.com, etc.)
+     * - "api.example.com:8443" - Hostname with specific port
+     * - "*.example.com:8443" - Wildcard subdomain with specific port
+     *
+     * ## Wildcard Rules
+     *
+     * - "*" at the start means "any subdomain" but NOT the root domain
+     *   - "*.example.com" matches "api.example.com" but NOT "example.com"
+     *   - To allow both, add both entries: ["*.example.com", "example.com"]
+     *
+     * - Wildcards only supported at the subdomain level
+     *   - Valid: "*.example.com", "*.api.example.com"
+     *   - Invalid: "api.*.com", "*", "example.*"
+     *
+     * ## Port Matching
+     *
+     * - If no port specified: matches any port on that host
+     *   - "api.example.com" matches api.example.com:80, api.example.com:443, api.example.com:8080
+     *
+     * - If port specified: matches only that specific port
+     *   - "api.example.com:443" matches ONLY api.example.com:443
+     *   - Does NOT match api.example.com:80 or api.example.com:8443
+     *
+     * ## Restrictions
+     *
+     * The following are blocked and will cause validation errors:
+     * - Private IP ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
+     * - Loopback addresses: 127.0.0.0/8, ::1
+     * - Link-local addresses: 169.254.0.0/16, fe80::/10
+     * - Non-globally resolvable hostnames: localhost, *.local, *.internal
+     *
+     * ## Examples
+     *
+     * 1. Single API endpoint:
+     *    allowed_hosts: ["api.example.com"]
+     *
+     * 2. Multiple environments:
+     *    allowed_hosts: ["api.prod.example.com", "api.staging.example.com"]
+     *
+     * 3. All subdomains of a service:
+     *    allowed_hosts: ["*.service.example.com", "service.example.com"]
+     *
+     * 4. Specific port (e.g., non-standard HTTPS):
+     *    allowed_hosts: ["api.example.com:8443"]
+     *
+     * @generated from field: repeated string allowed_hosts = 1;
+     */
+    allowedHosts?: string[];
+    /**
+     * Optional TLS configuration for the upstream connection.
+     *
+     * If not specified:
+     * - The protocol (HTTP/HTTPS) is forwarded from the incoming request
+     * - HTTP requests are proxied as HTTP
+     * - HTTPS requests are proxied as HTTPS using the system's default trust store
+     *   (publicly trusted Certificate Authorities like Let's Encrypt, DigiCert, etc.)
+     *
+     * If specified:
+     * - For MODE_SERVER_ONLY: Validates the server certificate against the provided ca_bundle
+     * - For MODE_MTLS: Performs mutual TLS authentication with client certificate
+     *
+     * Use this when:
+     * - Upstream uses self-signed certificates (provide custom ca_bundle)
+     * - Upstream requires mutual TLS (provide client certificate and private key)
+     * - Need to pin specific CA certificates for security
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsDefinition tls = 2;
+     */
+    tls?: TlsDefinitionJson;
+    /**
+     * Dynamic headers to inject into every proxied request using template variables.
+     *
+     * This field is for headers that require DYNAMIC values resolved from template variables.
+     * The caller can always submit static headers directly with each request - this field
+     * is specifically for injecting headers that use variable substitution (e.g., %ACCESS_TOKEN%).
+     *
+     * ## When to Use inject_headers
+     *
+     * Use this field when you need to inject headers with:
+     * - Values that change per request or per user (tokens, session IDs)
+     * - Values that come from user configuration (API keys, tenant IDs)
+     * - Values that need to be kept secret (credentials, tokens)
+     * - Dynamic template substitution using %VARIABLE% syntax
+     *
+     * ## When NOT to Use inject_headers
+     *
+     * Do NOT use this field for:
+     * - Static headers that never change (use direct headers in the request)
+     * - Headers that the caller controls (they can submit these directly)
+     * - Constant values like "Content-Type: application/json"
+     *
+     * The caller can always add, modify, or override headers in their individual requests.
+     * This field is for headers that the plugin definition requires to be injected with
+     * dynamic values before reaching the upstream service.
+     *
+     * ## Header Processing
+     *
+     * The map key is the HTTP header name (e.g., "Authorization", "X-Api-Key").
+     * Header names are case-insensitive per RFC 7230 but will be sent as specified.
+     *
+     * If the same header name appears in both inject_headers and the caller's request:
+     * - The inject_headers value takes precedence (overrides caller's value)
+     * - This ensures plugin-level authentication/configuration is always applied
+     *
+     * ## Common Patterns
+     *
+     * - "Authorization": "Bearer %ACCESS_TOKEN%" - Dynamic OAuth2 token
+     * - "X-Api-Key": "%API_KEY%" - User-provided API key
+     * - "X-Request-ID": "%CORRELATION_ID%" - Tracing identifier
+     * - "X-Tenant-ID": "%TENANT_ID%" - Multi-tenant identifier
+     *
+     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderTemplate> inject_headers = 3;
+     */
+    injectHeaders?: {
+        [key: string]: HeaderTemplateJson;
+    };
+};
+/**
+ * Describes the message mochabugapis.adapt.plugins.v1.HttpProxyDefinition.
+ * Use `create(HttpProxyDefinitionSchema)` to create a new message.
+ */
+export declare const HttpProxyDefinitionSchema: GenMessage<HttpProxyDefinition, {
+    jsonType: HttpProxyDefinitionJson;
+}>;
+/**
+ * HeaderTemplate defines a template string using Envoy-style %VAR% syntax
+ * for dynamic header value substitution.
+ *
+ * ## Template Syntax
+ *
+ * Variables are enclosed in percent signs: %VARIABLE_NAME%
+ *
+ * Variable names must:
+ * - Start with a letter or underscore
+ * - Contain only letters, numbers, and underscores
+ * - Be case-sensitive
+ *
+ * ## Examples
+ *
+ * 1. Bearer Token:
+ *    template: "Bearer %ACCESS_TOKEN%"
+ *    Result: "Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
+ *
+ * 2. API Key:
+ *    template: "ApiKey %API_KEY%"
+ *    Result: "ApiKey sk_live_51HqG8sKj..."
+ *
+ * 3. Multiple Variables:
+ *    template: "%TENANT_ID%:%USER_ID%"
+ *    Result: "org_123:user_456"
+ *
+ * 4. Mixed Static and Dynamic:
+ *    template: "v1.0/%API_VERSION%/client/%CLIENT_ID%"
+ *    Result: "v1.0/2024-01/client/client_abc123"
+ *
+ * ## Escaping Literal Percent Signs
+ *
+ * To include a literal percent sign (%) in the header value, double it:
+ *
+ * - template: "100%%" → Result: "100%"
+ * - template: "Completion: 95%% done" → Result: "Completion: 95% done"
+ * - template: "%%VAR%%" → Result: "%VAR%"
+ *
+ * ## Variable Resolution
+ *
+ * Template variables are provided by users when they configure or use the plugin.
+ * For system services, plugin authors provide the variable values.
+ *
+ * The resolution process is transparent:
+ * - Users see which hostname will receive the request (from allowed_hosts)
+ * - Users see which header is being modified
+ * - Users are prompted to provide values for each variable
+ *
+ * This ensures users know exactly what data they are sending and where it goes.
+ *
+ * If a variable is not provided, the header injection will fail at runtime,
+ * and the proxy request will not be sent.
+ *
+ * ## Security Considerations
+ *
+ * By default, template variables are treated as SECRETS.
+ *
+ * Set `plaintext: true` if the variable contains non-sensitive data like:
+ * - User IDs (not passwords)
+ * - Tenant/Organization IDs
+ * - Request correlation IDs
+ * - API version numbers
+ * - Public configuration values
+ *
+ * DO NOT set `plaintext: true` for:
+ * - Access tokens, API keys, passwords
+ * - Session tokens, JWTs
+ * - Private keys, certificates
+ * - Any credential material
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HeaderTemplate
+ */
+export type HeaderTemplate = Message<"mochabugapis.adapt.plugins.v1.HeaderTemplate"> & {
+    /**
+     * The template string using %VAR% syntax.
+     *
+     * Pattern: %VARIABLE_NAME% where VARIABLE_NAME matches [A-Za-z_][A-Za-z0-9_]*
+     * Escape literal %: use %%
+     *
+     * @generated from field: string template = 1;
+     */
+    template: string;
+    /**
+     * If true, variables in this template are NOT treated as secrets.
+     *
+     * Only set to true for non-sensitive identifiers like user IDs,
+     * tenant IDs, request IDs, or public configuration values.
+     *
+     * Default: false (variables are secrets)
+     *
+     * @generated from field: bool plaintext = 2;
+     */
+    plaintext: boolean;
+};
+/**
+ * HeaderTemplate defines a template string using Envoy-style %VAR% syntax
+ * for dynamic header value substitution.
+ *
+ * ## Template Syntax
+ *
+ * Variables are enclosed in percent signs: %VARIABLE_NAME%
+ *
+ * Variable names must:
+ * - Start with a letter or underscore
+ * - Contain only letters, numbers, and underscores
+ * - Be case-sensitive
+ *
+ * ## Examples
+ *
+ * 1. Bearer Token:
+ *    template: "Bearer %ACCESS_TOKEN%"
+ *    Result: "Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
+ *
+ * 2. API Key:
+ *    template: "ApiKey %API_KEY%"
+ *    Result: "ApiKey sk_live_51HqG8sKj..."
+ *
+ * 3. Multiple Variables:
+ *    template: "%TENANT_ID%:%USER_ID%"
+ *    Result: "org_123:user_456"
+ *
+ * 4. Mixed Static and Dynamic:
+ *    template: "v1.0/%API_VERSION%/client/%CLIENT_ID%"
+ *    Result: "v1.0/2024-01/client/client_abc123"
+ *
+ * ## Escaping Literal Percent Signs
+ *
+ * To include a literal percent sign (%) in the header value, double it:
+ *
+ * - template: "100%%" → Result: "100%"
+ * - template: "Completion: 95%% done" → Result: "Completion: 95% done"
+ * - template: "%%VAR%%" → Result: "%VAR%"
+ *
+ * ## Variable Resolution
+ *
+ * Template variables are provided by users when they configure or use the plugin.
+ * For system services, plugin authors provide the variable values.
+ *
+ * The resolution process is transparent:
+ * - Users see which hostname will receive the request (from allowed_hosts)
+ * - Users see which header is being modified
+ * - Users are prompted to provide values for each variable
+ *
+ * This ensures users know exactly what data they are sending and where it goes.
+ *
+ * If a variable is not provided, the header injection will fail at runtime,
+ * and the proxy request will not be sent.
+ *
+ * ## Security Considerations
+ *
+ * By default, template variables are treated as SECRETS.
+ *
+ * Set `plaintext: true` if the variable contains non-sensitive data like:
+ * - User IDs (not passwords)
+ * - Tenant/Organization IDs
+ * - Request correlation IDs
+ * - API version numbers
+ * - Public configuration values
+ *
+ * DO NOT set `plaintext: true` for:
+ * - Access tokens, API keys, passwords
+ * - Session tokens, JWTs
+ * - Private keys, certificates
+ * - Any credential material
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HeaderTemplate
+ */
+export type HeaderTemplateJson = {
+    /**
+     * The template string using %VAR% syntax.
+     *
+     * Pattern: %VARIABLE_NAME% where VARIABLE_NAME matches [A-Za-z_][A-Za-z0-9_]*
+     * Escape literal %: use %%
+     *
+     * @generated from field: string template = 1;
+     */
+    template?: string;
+    /**
+     * If true, variables in this template are NOT treated as secrets.
+     *
+     * Only set to true for non-sensitive identifiers like user IDs,
+     * tenant IDs, request IDs, or public configuration values.
+     *
+     * Default: false (variables are secrets)
+     *
+     * @generated from field: bool plaintext = 2;
+     */
+    plaintext?: boolean;
+};
+/**
+ * Describes the message mochabugapis.adapt.plugins.v1.HeaderTemplate.
+ * Use `create(HeaderTemplateSchema)` to create a new message.
+ */
+export declare const HeaderTemplateSchema: GenMessage<HeaderTemplate, {
+    jsonType: HeaderTemplateJson;
+}>;
+/**
+ * TLS configuration defining the security requirements for upstream connections.
+ *
+ * Supports two authentication modes with flexible CA bundle placement.
+ *
+ * ## Security Model
+ *
+ * - Public certificates (CA bundles): Can be in definition OR config
+ * - Private keys and client certificates: MUST be in config (secrets)
+ *
+ * ## Mode Descriptions
+ *
+ * MODE_SERVER_ONLY: Validate server's certificate (standard HTTPS)
+ * - Client verifies server identity
+ * - Server does not verify client
+ * - Common for public APIs
+ *
+ * MODE_MTLS: Mutual authentication (both parties verify each other)
+ * - Client verifies server identity AND presents its own certificate
+ * - Server verifies client identity
+ * - Common for B2B integrations, internal services
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.TlsDefinition
+ */
+export type TlsDefinition = Message<"mochabugapis.adapt.plugins.v1.TlsDefinition"> & {
+    /**
+     * Select the TLS mode for the connection.
+     *
+     * @generated from field: mochabugapis.adapt.plugins.v1.TlsDefinition.Mode mode = 1;
+     */
+    mode: TlsDefinition_Mode;
+    /**
+     * The expected hostname for certificate verification (SNI - Server Name Indication).
+     *
+     * If present, the client will:
+     * 1. Send this hostname in the TLS SNI extension during the handshake
+     * 2. Verify that the server's certificate authenticates this specific hostname
+     *
+     * If not provided:
+     * - The hostname is derived from the target upstream address
+     * - For IP addresses, certificate verification may fail unless the cert includes the IP as a SAN
+     *
+     * ## Use Cases
+     *
+     * 1. **IP-based connections with hostname certificates:**
+     *    - Upstream address: 192.168.1.100:443
+     *    - certificate_host: "api.example.com"
+     *    - Server presents cert for api.example.com
+     *
+     * 2. **Load balancers or proxies:**
+     *    - Upstream address: lb.internal:443
+     *    - certificate_host: "api.example.com"
+     *    - Verify against the public hostname, not internal LB name
+     *
+     * 3. **Shared hosting / Virtual hosting:**
+     *    - Multiple services on same IP, different certs via SNI
+     *    - Server selects correct certificate based on SNI hostname
+     *
+     * ## Certificate Verification
+     *
+     * The server certificate must contain this hostname in either:
+     * - Common Name (CN) field
+     * - Subject Alternative Name (SAN) extension
+     *
+     * ## Format
+     *
+     * Must be a valid hostname (DNS name), not an IP address.
+     * Examples: "api.example.com", "service.internal", "*.example.com" (for wildcard matching)
+     *
+     * @generated from field: optional string certificate_host = 2;
+     */
+    certificateHost?: string;
+    /**
+     * Optional CA bundle for server certificate validation.
+     *
+     * ## Why CA Bundle in Definition?
+     *
+     * CA bundles contain PUBLIC certificates (not secrets), so they can be safely
+     * embedded in the plugin definition. This reduces configuration burden on users
+     * when the CA bundle is known ahead of time.
+     *
+     * ## When to Use This Field
+     *
+     * Set the CA bundle in the definition when:
+     * - The upstream service uses a self-signed certificate
+     * - The upstream uses a private/internal Certificate Authority
+     * - You want to pin specific CA certificates for security
+     * - The CA bundle is static and known at plugin authoring time
+     *
+     * ## When to Use TlsConfig.ca_bundle Instead
+     *
+     * Leave this empty and use TlsConfig.ca_bundle when:
+     * - Different users need different CA bundles
+     * - The CA bundle is dynamic or environment-specific
+     * - Users want to override the plugin's default CA bundle
+     *
+     * ## Configuration Rules
+     *
+     * For MODE_SERVER_ONLY:
+     * - At least one CA bundle must be provided (either here OR in TlsConfig)
+     * - If set here: users don't need to provide TlsConfig.ca_bundle
+     * - If NOT set here: users MUST provide TlsConfig.ca_bundle
+     *
+     * For MODE_MTLS:
+     * - Same CA bundle rules as MODE_SERVER_ONLY
+     * - Users must ALSO provide client certificate and private_key in TlsConfig
+     *
+     * ## Precedence
+     *
+     * If CA bundle is provided in both the definition AND TlsConfig:
+     * - TlsConfig.ca_bundle takes precedence (config overrides definition)
+     * - This allows users to override the plugin's default CA bundle if needed
+     *
+     * ## Format
+     *
+     * The CA bundle must be in PEM format (same as TlsConfig.ca_bundle).
+     * If a certificate chain is presented, the root CA must be included.
+     *
+     * IF this points to a file on the disk, then it will be loaded from there.
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 3;
+     */
+    caBundle?: File;
+};
+/**
+ * TLS configuration defining the security requirements for upstream connections.
+ *
+ * Supports two authentication modes with flexible CA bundle placement.
+ *
+ * ## Security Model
+ *
+ * - Public certificates (CA bundles): Can be in definition OR config
+ * - Private keys and client certificates: MUST be in config (secrets)
+ *
+ * ## Mode Descriptions
+ *
+ * MODE_SERVER_ONLY: Validate server's certificate (standard HTTPS)
+ * - Client verifies server identity
+ * - Server does not verify client
+ * - Common for public APIs
+ *
+ * MODE_MTLS: Mutual authentication (both parties verify each other)
+ * - Client verifies server identity AND presents its own certificate
+ * - Server verifies client identity
+ * - Common for B2B integrations, internal services
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.TlsDefinition
+ */
+export type TlsDefinitionJson = {
+    /**
+     * Select the TLS mode for the connection.
+     *
+     * @generated from field: mochabugapis.adapt.plugins.v1.TlsDefinition.Mode mode = 1;
+     */
+    mode?: TlsDefinition_ModeJson;
+    /**
+     * The expected hostname for certificate verification (SNI - Server Name Indication).
+     *
+     * If present, the client will:
+     * 1. Send this hostname in the TLS SNI extension during the handshake
+     * 2. Verify that the server's certificate authenticates this specific hostname
+     *
+     * If not provided:
+     * - The hostname is derived from the target upstream address
+     * - For IP addresses, certificate verification may fail unless the cert includes the IP as a SAN
+     *
+     * ## Use Cases
+     *
+     * 1. **IP-based connections with hostname certificates:**
+     *    - Upstream address: 192.168.1.100:443
+     *    - certificate_host: "api.example.com"
+     *    - Server presents cert for api.example.com
+     *
+     * 2. **Load balancers or proxies:**
+     *    - Upstream address: lb.internal:443
+     *    - certificate_host: "api.example.com"
+     *    - Verify against the public hostname, not internal LB name
+     *
+     * 3. **Shared hosting / Virtual hosting:**
+     *    - Multiple services on same IP, different certs via SNI
+     *    - Server selects correct certificate based on SNI hostname
+     *
+     * ## Certificate Verification
+     *
+     * The server certificate must contain this hostname in either:
+     * - Common Name (CN) field
+     * - Subject Alternative Name (SAN) extension
+     *
+     * ## Format
+     *
+     * Must be a valid hostname (DNS name), not an IP address.
+     * Examples: "api.example.com", "service.internal", "*.example.com" (for wildcard matching)
+     *
+     * @generated from field: optional string certificate_host = 2;
+     */
+    certificateHost?: string;
+    /**
+     * Optional CA bundle for server certificate validation.
+     *
+     * ## Why CA Bundle in Definition?
+     *
+     * CA bundles contain PUBLIC certificates (not secrets), so they can be safely
+     * embedded in the plugin definition. This reduces configuration burden on users
+     * when the CA bundle is known ahead of time.
+     *
+     * ## When to Use This Field
+     *
+     * Set the CA bundle in the definition when:
+     * - The upstream service uses a self-signed certificate
+     * - The upstream uses a private/internal Certificate Authority
+     * - You want to pin specific CA certificates for security
+     * - The CA bundle is static and known at plugin authoring time
+     *
+     * ## When to Use TlsConfig.ca_bundle Instead
+     *
+     * Leave this empty and use TlsConfig.ca_bundle when:
+     * - Different users need different CA bundles
+     * - The CA bundle is dynamic or environment-specific
+     * - Users want to override the plugin's default CA bundle
+     *
+     * ## Configuration Rules
+     *
+     * For MODE_SERVER_ONLY:
+     * - At least one CA bundle must be provided (either here OR in TlsConfig)
+     * - If set here: users don't need to provide TlsConfig.ca_bundle
+     * - If NOT set here: users MUST provide TlsConfig.ca_bundle
+     *
+     * For MODE_MTLS:
+     * - Same CA bundle rules as MODE_SERVER_ONLY
+     * - Users must ALSO provide client certificate and private_key in TlsConfig
+     *
+     * ## Precedence
+     *
+     * If CA bundle is provided in both the definition AND TlsConfig:
+     * - TlsConfig.ca_bundle takes precedence (config overrides definition)
+     * - This allows users to override the plugin's default CA bundle if needed
+     *
+     * ## Format
+     *
+     * The CA bundle must be in PEM format (same as TlsConfig.ca_bundle).
+     * If a certificate chain is presented, the root CA must be included.
+     *
+     * IF this points to a file on the disk, then it will be loaded from there.
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 3;
+     */
+    caBundle?: FileJson;
+};
+/**
+ * Describes the message mochabugapis.adapt.plugins.v1.TlsDefinition.
+ * Use `create(TlsDefinitionSchema)` to create a new message.
+ */
+export declare const TlsDefinitionSchema: GenMessage<TlsDefinition, {
+    jsonType: TlsDefinitionJson;
+}>;
+/**
+ * Mode specifies which TLS configuration to use.
+ *
+ * @generated from enum mochabugapis.adapt.plugins.v1.TlsDefinition.Mode
+ */
+export declare enum TlsDefinition_Mode {
+    /**
+     * Default value. Invalid.
+     *
+     * @generated from enum value: MODE_UNSPECIFIED = 0;
+     */
+    UNSPECIFIED = 0,
+    /**
+     * Mutual TLS: Both client and server authenticate each other.
+     *
+     * Configuration requirements:
+     * - CA bundle: Set in TlsDefinition.ca_bundle OR TlsConfig.ca_bundle (at least one required)
+     * - Client certificate: REQUIRED in TlsConfig.certificate
+     * - Client private key: REQUIRED in TlsConfig.private_key
+     *
+     * Use when:
+     * - Upstream service requires client certificate authentication
+     * - Both parties need strong cryptographic authentication
+     * - Common in B2B APIs, internal microservices, banking/financial APIs
+     *
+     * @generated from enum value: MODE_MTLS = 1;
+     */
+    MTLS = 1,
+    /**
+     * Server-only validation: Client verifies server identity.
+     *
+     * Configuration requirements:
+     * - CA bundle: Set in TlsDefinition.ca_bundle OR TlsConfig.ca_bundle (at least one required)
+     * - Client certificate: NOT used
+     * - Client private key: NOT used
+     *
+     * Use when:
+     * - Standard HTTPS with server authentication only
+     * - Upstream uses self-signed or internal CA certificates
+     * - Want to pin specific CA certificates for security
+     * - Most common mode for external APIs
+     *
+     * @generated from enum value: MODE_SERVER_ONLY = 2;
+     */
+    SERVER_ONLY = 2
+}
+/**
+ * Mode specifies which TLS configuration to use.
+ *
+ * @generated from enum mochabugapis.adapt.plugins.v1.TlsDefinition.Mode
+ */
+export type TlsDefinition_ModeJson = "MODE_UNSPECIFIED" | "MODE_MTLS" | "MODE_SERVER_ONLY";
+/**
+ * Describes the enum mochabugapis.adapt.plugins.v1.TlsDefinition.Mode.
+ */
+export declare const TlsDefinition_ModeSchema: GenEnum<TlsDefinition_Mode, TlsDefinition_ModeJson>;
+/**
+ * The actual TLS configuration containing runtime secrets.
+ *
+ * This provides the secret/dynamic parts of the TLS configuration that cannot
+ * be embedded in the plugin definition (private keys, user-specific certificates).
+ *
+ * ## Relationship to TlsDefinition
+ *
+ * - TlsDefinition: Defines the TLS mode and optionally includes the CA bundle (public cert)
+ * - TlsConfig: Provides runtime secrets (private keys, client certificates)
+ *
+ * ## Configuration Requirements
+ *
+ * For MODE_SERVER_ONLY:
+ * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
+ * - certificate: NOT used
+ * - private_key: NOT used
+ *
+ * For MODE_MTLS:
+ * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
+ * - certificate: REQUIRED (client certificate for mutual TLS)
+ * - private_key: REQUIRED (client private key for mutual TLS)
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.TlsConfig
+ */
+export type TlsConfig = Message<"mochabugapis.adapt.plugins.v1.TlsConfig"> & {
+    /**
+     * Optional CA bundle for server certificate validation.
+     *
+     * The CA bundle in PEM format containing one or more trusted Certificate Authorities.
+     * The content of the file must be PEM format after decoding.
+     * If a certificate chain is presented, the root CA must be included.
+     *
+     * ## When to Provide This
+     *
+     * REQUIRED if TlsDefinition.ca_bundle is NOT set.
+     * OPTIONAL if TlsDefinition.ca_bundle is set (this will override the definition's CA bundle).
+     *
+     * ## Override Behavior
+     *
+     * If both TlsDefinition.ca_bundle and TlsConfig.ca_bundle are provided:
+     * - This config value takes precedence
+     * - Allows users to override the plugin author's default CA bundle
+     *
+     * ## Use Cases for Override
+     *
+     * - User's organization has different root CAs
+     * - Testing with different certificate chains
+     * - Environment-specific CA requirements
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 1;
+     */
+    caBundle?: File;
+    /**
+     * Optional client certificate for mutual TLS authentication.
+     *
+     * The certificate in PEM format used to authenticate the client to the server.
+     * The content of the file must be PEM format after decoding.
+     * If a certificate chain is presented, the client certificate must be the first one.
+     *
+     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
+     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File certificate = 2;
+     */
+    certificate?: File;
+    /**
+     * Optional client private key for mutual TLS authentication.
+     *
+     * The private key in PEM format corresponding to the client certificate.
+     * The content of the file must be PEM format after decoding.
+     * The content must contain a PRIVATE KEY block.
+     *
+     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
+     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File private_key = 3;
+     */
+    privateKey?: File;
+};
+/**
+ * The actual TLS configuration containing runtime secrets.
+ *
+ * This provides the secret/dynamic parts of the TLS configuration that cannot
+ * be embedded in the plugin definition (private keys, user-specific certificates).
+ *
+ * ## Relationship to TlsDefinition
+ *
+ * - TlsDefinition: Defines the TLS mode and optionally includes the CA bundle (public cert)
+ * - TlsConfig: Provides runtime secrets (private keys, client certificates)
+ *
+ * ## Configuration Requirements
+ *
+ * For MODE_SERVER_ONLY:
+ * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
+ * - certificate: NOT used
+ * - private_key: NOT used
+ *
+ * For MODE_MTLS:
+ * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
+ * - certificate: REQUIRED (client certificate for mutual TLS)
+ * - private_key: REQUIRED (client private key for mutual TLS)
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.TlsConfig
+ */
+export type TlsConfigJson = {
+    /**
+     * Optional CA bundle for server certificate validation.
+     *
+     * The CA bundle in PEM format containing one or more trusted Certificate Authorities.
+     * The content of the file must be PEM format after decoding.
+     * If a certificate chain is presented, the root CA must be included.
+     *
+     * ## When to Provide This
+     *
+     * REQUIRED if TlsDefinition.ca_bundle is NOT set.
+     * OPTIONAL if TlsDefinition.ca_bundle is set (this will override the definition's CA bundle).
+     *
+     * ## Override Behavior
+     *
+     * If both TlsDefinition.ca_bundle and TlsConfig.ca_bundle are provided:
+     * - This config value takes precedence
+     * - Allows users to override the plugin author's default CA bundle
+     *
+     * ## Use Cases for Override
+     *
+     * - User's organization has different root CAs
+     * - Testing with different certificate chains
+     * - Environment-specific CA requirements
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 1;
+     */
+    caBundle?: FileJson;
+    /**
+     * Optional client certificate for mutual TLS authentication.
+     *
+     * The certificate in PEM format used to authenticate the client to the server.
+     * The content of the file must be PEM format after decoding.
+     * If a certificate chain is presented, the client certificate must be the first one.
+     *
+     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
+     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File certificate = 2;
+     */
+    certificate?: FileJson;
+    /**
+     * Optional client private key for mutual TLS authentication.
+     *
+     * The private key in PEM format corresponding to the client certificate.
+     * The content of the file must be PEM format after decoding.
+     * The content must contain a PRIVATE KEY block.
+     *
+     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
+     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.File private_key = 3;
+     */
+    privateKey?: FileJson;
+};
+/**
+ * Describes the message mochabugapis.adapt.plugins.v1.TlsConfig.
+ * Use `create(TlsConfigSchema)` to create a new message.
+ */
+export declare const TlsConfigSchema: GenMessage<TlsConfig, {
+    jsonType: TlsConfigJson;
+}>;
+/**
+ * The actual HTTP proxy configuration containing runtime values
+ *
+ * This message provides the actual configuration values for the HTTP proxy service,
+ * including TLS certificates and template variable values for header injection.
+ *
+ * ## Relationship to HttpProxyDefinition
+ *
+ * - HttpProxyDefinition: Defines the schema (which headers to inject, template syntax, TLS mode)
+ * - HttpProxyConfig: Provides the actual values (certificates, variable values)
+ *
+ * ## Example
+ *
+ * Given a definition with:
+ * - inject_headers["Authorization"].template.template = "Bearer %ACCESS_TOKEN%"
+ * - tls.mode = MODE_SERVER_ONLY
+ *
+ * The config would provide:
+ * - tls_config.ca_bundle = <actual CA certificate>
+ * - template_variables["ACCESS_TOKEN"] = "eyJhbGci..." (the actual token)
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyConfig
+ */
+export type HttpProxyConfig = Message<"mochabugapis.adapt.plugins.v1.HttpProxyConfig"> & {
+    /**
+     * The actual TLS configuration with certificates and private keys.
+     *
+     * REQUIRED if HttpProxyDefinition.tls is set.
+     * MUST NOT be set if HttpProxyDefinition.tls is not set.
+     *
+     * For MODE_SERVER_ONLY:
+     * - Provide only ca_bundle
+     * - Leave certificate and private_key empty
+     *
+     * For MODE_MTLS:
+     * - Provide ca_bundle, certificate, AND private_key
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsConfig tls_config = 1;
+     */
+    tlsConfig?: TlsConfig;
+    /**
+     * Template variable values for dynamic header injection, organized by header name.
+     *
+     * This provides the actual values for template variables used in HttpProxyDefinition.inject_headers.
+     * Each header that uses template variables needs its variables resolved here.
+     *
+     * ## Structure
+     *
+     * Outer map key: HTTP header name (must match a key in HttpProxyDefinition.inject_headers)
+     * Outer map value: Map of variable names to their actual values for that specific header
+     *
+     * This structure mirrors HttpProxyDefinition.inject_headers, making it clear
+     * which variables belong to which header template.
+     *
+     * ## Variable Name Requirements
+     *
+     * Variable names must match the %VARIABLE% patterns used in the header's template:
+     * - Start with a letter or underscore
+     * - Contain only letters, numbers, and underscores
+     * - Case-sensitive (e.g., %ACCESS_TOKEN% requires variable name "ACCESS_TOKEN")
+     *
+     * ## Examples
+     *
+     * Given a definition with:
+     * - inject_headers["Authorization"].template = "Bearer %ACCESS_TOKEN%"
+     * - inject_headers["X-Correlation"].template = "%TENANT_ID%:%USER_ID%"
+     *
+     * The config must provide:
+     * - header_variables["Authorization"]["ACCESS_TOKEN"] = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
+     * - header_variables["X-Correlation"]["TENANT_ID"] = "org_123"
+     * - header_variables["X-Correlation"]["USER_ID"] = "user_456"
+     *
+     * ## Security
+     *
+     * All values are stored securely and encrypted at rest.
+     * The HeaderTemplate.plaintext flag (in the definition) controls whether
+     * the variable value is treated as a secret or shown in logs/UI.
+     *
+     * ## Variable Resolution Process
+     *
+     * Users of the plugin are prompted to provide values for all template variables.
+     * For system services, the plugin author provides the values programmatically.
+     *
+     * During configuration, it is fully transparent to users:
+     * - Which hostname the request will be sent to (from allowed_hosts)
+     * - Which headers are being injected
+     * - What template variables are required
+     * - Whether each variable is a secret or plaintext
+     *
+     * Users see exactly what data they are providing and where it will be sent.
+     *
+     * ## Runtime Behavior
+     *
+     * If a variable referenced in a header template is missing from this config,
+     * the header injection will fail at runtime and the request will not be sent.
+     *
+     * ## Validation
+     *
+     * - Header names in this map MUST match headers in HttpProxyDefinition.inject_headers
+     * - All variables referenced in each header's template must be provided
+     * - Extra variables (not referenced in the template) are ignored
+     *
+     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderVariables> header_variables = 2;
+     */
+    headerVariables: {
+        [key: string]: HeaderVariables;
+    };
+};
+/**
+ * The actual HTTP proxy configuration containing runtime values
+ *
+ * This message provides the actual configuration values for the HTTP proxy service,
+ * including TLS certificates and template variable values for header injection.
+ *
+ * ## Relationship to HttpProxyDefinition
+ *
+ * - HttpProxyDefinition: Defines the schema (which headers to inject, template syntax, TLS mode)
+ * - HttpProxyConfig: Provides the actual values (certificates, variable values)
+ *
+ * ## Example
+ *
+ * Given a definition with:
+ * - inject_headers["Authorization"].template.template = "Bearer %ACCESS_TOKEN%"
+ * - tls.mode = MODE_SERVER_ONLY
+ *
+ * The config would provide:
+ * - tls_config.ca_bundle = <actual CA certificate>
+ * - template_variables["ACCESS_TOKEN"] = "eyJhbGci..." (the actual token)
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyConfig
+ */
+export type HttpProxyConfigJson = {
+    /**
+     * The actual TLS configuration with certificates and private keys.
+     *
+     * REQUIRED if HttpProxyDefinition.tls is set.
+     * MUST NOT be set if HttpProxyDefinition.tls is not set.
+     *
+     * For MODE_SERVER_ONLY:
+     * - Provide only ca_bundle
+     * - Leave certificate and private_key empty
+     *
+     * For MODE_MTLS:
+     * - Provide ca_bundle, certificate, AND private_key
+     *
+     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsConfig tls_config = 1;
+     */
+    tlsConfig?: TlsConfigJson;
+    /**
+     * Template variable values for dynamic header injection, organized by header name.
+     *
+     * This provides the actual values for template variables used in HttpProxyDefinition.inject_headers.
+     * Each header that uses template variables needs its variables resolved here.
+     *
+     * ## Structure
+     *
+     * Outer map key: HTTP header name (must match a key in HttpProxyDefinition.inject_headers)
+     * Outer map value: Map of variable names to their actual values for that specific header
+     *
+     * This structure mirrors HttpProxyDefinition.inject_headers, making it clear
+     * which variables belong to which header template.
+     *
+     * ## Variable Name Requirements
+     *
+     * Variable names must match the %VARIABLE% patterns used in the header's template:
+     * - Start with a letter or underscore
+     * - Contain only letters, numbers, and underscores
+     * - Case-sensitive (e.g., %ACCESS_TOKEN% requires variable name "ACCESS_TOKEN")
+     *
+     * ## Examples
+     *
+     * Given a definition with:
+     * - inject_headers["Authorization"].template = "Bearer %ACCESS_TOKEN%"
+     * - inject_headers["X-Correlation"].template = "%TENANT_ID%:%USER_ID%"
+     *
+     * The config must provide:
+     * - header_variables["Authorization"]["ACCESS_TOKEN"] = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
+     * - header_variables["X-Correlation"]["TENANT_ID"] = "org_123"
+     * - header_variables["X-Correlation"]["USER_ID"] = "user_456"
+     *
+     * ## Security
+     *
+     * All values are stored securely and encrypted at rest.
+     * The HeaderTemplate.plaintext flag (in the definition) controls whether
+     * the variable value is treated as a secret or shown in logs/UI.
+     *
+     * ## Variable Resolution Process
+     *
+     * Users of the plugin are prompted to provide values for all template variables.
+     * For system services, the plugin author provides the values programmatically.
+     *
+     * During configuration, it is fully transparent to users:
+     * - Which hostname the request will be sent to (from allowed_hosts)
+     * - Which headers are being injected
+     * - What template variables are required
+     * - Whether each variable is a secret or plaintext
+     *
+     * Users see exactly what data they are providing and where it will be sent.
+     *
+     * ## Runtime Behavior
+     *
+     * If a variable referenced in a header template is missing from this config,
+     * the header injection will fail at runtime and the request will not be sent.
+     *
+     * ## Validation
+     *
+     * - Header names in this map MUST match headers in HttpProxyDefinition.inject_headers
+     * - All variables referenced in each header's template must be provided
+     * - Extra variables (not referenced in the template) are ignored
+     *
+     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderVariables> header_variables = 2;
+     */
+    headerVariables?: {
+        [key: string]: HeaderVariablesJson;
+    };
+};
+/**
+ * Describes the message mochabugapis.adapt.plugins.v1.HttpProxyConfig.
+ * Use `create(HttpProxyConfigSchema)` to create a new message.
+ */
+export declare const HttpProxyConfigSchema: GenMessage<HttpProxyConfig, {
+    jsonType: HttpProxyConfigJson;
+}>;
+/**
+ * Variable values for a specific header's template substitution.
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HeaderVariables
+ */
+export type HeaderVariables = Message<"mochabugapis.adapt.plugins.v1.HeaderVariables"> & {
+    /**
+     * Map of variable name to value.
+     *
+     * Key: Variable name matching %VAR_NAME% in the header's template
+     * Value: The actual value to substitute
+     *
+     * @generated from field: map<string, string> variables = 1;
+     */
+    variables: {
+        [key: string]: string;
+    };
+};
+/**
+ * Variable values for a specific header's template substitution.
+ *
+ * @generated from message mochabugapis.adapt.plugins.v1.HeaderVariables
+ */
+export type HeaderVariablesJson = {
+    /**
+     * Map of variable name to value.
+     *
+     * Key: Variable name matching %VAR_NAME% in the header's template
+     * Value: The actual value to substitute
+     *
+     * @generated from field: map<string, string> variables = 1;
+     */
+    variables?: {
+        [key: string]: string;
+    };
+};
+/**
+ * Describes the message mochabugapis.adapt.plugins.v1.HeaderVariables.
+ * Use `create(HeaderVariablesSchema)` to create a new message.
+ */
+export declare const HeaderVariablesSchema: GenMessage<HeaderVariables, {
+    jsonType: HeaderVariablesJson;
+}>;
+//# sourceMappingURL=http_proxy_service_pb.d.ts.map