Interlays API

Interlays are Gateway-managed native protocol listeners. They give applications a stable Gateway address for supported database and cache traffic while Gateway applies endpoint identity, RBAC, command policy, traffic masking, traffic mirroring, and telemetry before the backend receives a request.

Use this API to create, configure, start, stop, inspect, and remove a listener. It is focused on listener lifecycle and runtime configuration.

What An Interlay Manages

• A native listener bound to one primary endpoint.
• TLS, listener configuration, and endpoint identity context.
• Supported command-policy and audit settings.
• Traffic Masking before backend egress.
• Traffic Mirroring to secondary endpoints without changing the primary client response.
• Listener lifecycle and safe time-series analysis.

Route Map

Legacy Mirror Mode

An interlay can be configured for legacy best-effort primary-to-secondary fanout with settings.mirror. The configured endpoint remains the primary and is the only response path for clients. This setting is separate from Endpoint comparison arenas and runs.

{
  "settings": {
    "mirror": {
      "enabled": true,
      "mode": "mirror",
      "mirror_endpoint_uuids": ["secondary-endpoint-uuid"],
      "mirror_reads": true,
      "mirror_writes": false,
      "sample_ratio": 0.1,
      "max_in_flight_per_mirror": 128
    }
  }
}

Mirror endpoints must be direct endpoints in the same organization and have the same endpoint kind as the primary. The mirror list cannot include the primary endpoint or an attached migration's primary target endpoint. Secondary results are best-effort evidence and do not alter the primary client response.

Use the dedicated Endpoint Comparison APIs for durable head-to-head arenas, indefinite runs, symmetric request evidence, and guarded endpoint completion. Endpoint comparison rejects targets that overlap an active legacy Mirror Mode configuration.

List Interlays

Create An Interlay

Create an interlay with an organization endpoint and the listener settings appropriate for its endpoint kind.

POST /api/v1/interlays
Authorization: Bearer <token>
Content-Type: application/json

{
  "id": "orders-cache",
  "endpoint": "550e8400-e29b-41d4-a716-446655440001",
  "port": 6366,
  "settings": {},
  "tls": false
}

The endpoint must be reachable through the requesting organization, and callers need permission to manage the listener and its endpoint. The response reports whether the listener is running; use the lifecycle routes to stop or restart it as needed.

Configure Important Traffic Controls

Masking and mirroring are independent, additive settings on an interlay. Configure only settings supported by the endpoint processor and backend profile:

{
  "settings": {
    "mirror": {
      "enabled": true,
      "mode": "mirror",
      "mirror_endpoint_uuids": ["7a2e4f1b-0000-0000-0000-000000000000"],
      "mirror_reads": true,
      "mirror_writes": false,
      "sample_ratio": 0.1,
      "max_in_flight_per_mirror": 128
    },
    "masking": {
      "request_terms": []
    }
  }
}

Use the dedicated feature guides for rule semantics, supported request surfaces, failure behavior, and operational guidance:

• Traffic Masking
• Traffic Mirroring

Operate The Listener

Use the lifecycle routes after provisioning or configuration changes:

POST /api/v1/interlays/{interlay}/start
POST /api/v1/interlays/{interlay}/stop
GET /api/v1/interlays/{interlay}/analysis/timeseries

Review endpoint health, RBAC, TLS, masking, and mirror capacity before directing production clients to a listener. The analysis route provides listener-level evidence without exposing backend credentials.

Related Docs

• Gateway
• Endpoint Management
• Traffic Masking
• Traffic Mirroring
• Eden VPN