Generic-HTTP receiver

The generic-HTTP receiver is the bring-your-own-gateway ingest path. If your edge can emit accessible HTTP traffic logs, it can feed SOAP-2-REST — no dedicated connector required. The dedicated connectors and the generic receiver share the same downstream pipeline, so traffic that arrives this way is discovered, aggregated, and curated identically.

A note on vendor names. This page describes a vendor-neutral ingest endpoint. Any gateway, load balancer, application server, or appliance can use it. That is interoperability information, not a comparison.

---

How it works

The receiver exposes a single ingest endpoint:

POST /ingest/v1/generic/traffic

Your edge POSTs one JSON envelope per transaction to the endpoint. The receiver validates the envelope, deduplicates it, and writes it to the unified traffic-log table. From there it flows into the same aggregation tables that drive discovery and the same learned examples the dedicated connectors populate.

The endpoint can run as a public-facing ingest service or, for edges without internet egress, as a local container inside your VPC parallel to the F5 relay — mirroring the relay pattern.

---

The JSON envelope

The envelope is a published, stable contract. The current version is "1". Send Content-Type: application/json and a body of this shape:

| Field | Required | Notes | |---|---|---| | envelope_version | yes | Must be "1". | | gateway_type | yes | One of the recognized values (see below). Use generic when none fits. | | event_id | yes | Your transaction/correlation key. Used for dedup. Max 128 chars. | | timestamp_iso | yes | RFC 3339 timestamp. Events older than 24h are silently dropped. | | frontend_uri | yes | The consumer-facing request URI. Max 2048 chars. | | backend_uri | yes | The resolved backend URL. Max 2048 chars. | | client_ip | yes | Original consumer IP (a valid IP address). | | gateway_client_ip | yes | The gateway's own immediate-hop IP (a valid IP address). | | front_virtual_server | yes | Front-end virtual server / service name. Max 512 chars. | | http_method | yes | GET / POST / PUT / PATCH / DELETE / OPTIONS / HEAD. | | http_status | yes | Integer 100–599. | | latency_ms | yes | Integer ≥ 0. | | back_virtual_server | no | Backend pool / service name. | | request_payload | no | Base64-encoded request body (≤ 30 MB decoded). | | response_payload | no | Base64-encoded response body (≤ 30 MB decoded). | | request_headers | no | JSON object of request headers. | | response_headers | no | JSON object of response headers. | | tls_version / cipher_suite | no | Connection metadata. | | correlation_id | no | An additional correlation key, if distinct from event_id. | | vendor_extensions | no | JSON object for vendor-specific extras (≤ 64 KB serialized). |

The total POST body is capped at 30 MB; an oversized body is rejected with S2R-INGEST-0413.

Recognized gateway_type values: f5, datapower, citrix_netscaler, haproxy, nginx, kemp, a10, radware, layer7, oracle-oag, webmethods, akana, tibco_mashery, and generic.

Example

{
  "envelope_version": "1",
  "gateway_type": "generic",
  "event_id": "tx-2026-05-25-0001",
  "timestamp_iso": "2026-05-25T08:00:00Z",
  "frontend_uri": "/SoapService/services/Charge",
  "backend_uri": "http://10.40.25.144:9080/SoapService/services/Charge",
  "client_ip": "10.0.0.5",
  "gateway_client_ip": "10.40.25.170",
  "front_virtual_server": "soap-vip-payments",
  "http_method": "POST",
  "http_status": 200,
  "latency_ms": 42
}

---

Per-vendor parsers

Most senders POST the canonical envelope above. For edges that emit a vendor-native log format (e.g. a syslog frame or a vendor JSON event) rather than the envelope, the receiver can route the raw body through a per-vendor parser that normalizes it into the envelope.

Select a parser with either:

• the X-S2R-Vendor: <gateway_type> request header (takes priority), or
• the ?parser=<gateway_type> query parameter.

When no hint is given, the body is decoded directly as canonical-envelope JSON. The platform ships parsers for the dedicated-connector vendors (DataPower, Citrix NetScaler, HAProxy, nginx, Kemp, A10, Radware, Layer7, webMethods, Akana, TIBCO Mashery, Oracle OAG) plus an identity parser for generic.

---

Authentication

The ingest endpoint is protected with HTTP Basic authentication, compared in constant time. Configure the credential at deploy time. (A no-auth mode exists strictly for first-boot smoke testing and emits a loud warning at startup; production deployments set a credential.)

---

Validation, dedup, and the dead-letter queue

The receiver is built to never lose a record silently and to never make a misbehaving sender retry forever:

• Validation collects all envelope violations at once (not just the first) so a malformed sender gets the full picture.
• Duplicates (same event_id) are detected and acknowledged without double-counting.
• Stale events (timestamp older than 24h) are silently dropped with a 200 so the sender stops retrying.
• Parse / validation failures are written to a dead-letter queue (DLQ) — the raw body, the detected format, the parse error, and the source IP are preserved for inspection — and the receiver returns 200 so a permanently-malformed event is not retried indefinitely. A structured log line per DLQ write feeds a monitoring metric so operators can watch DLQ volume.

A genuine server-side error (e.g. the database is unreachable) returns S2R-INGEST-0500 so the sender does retry.

---

Related

• Connectors overview — the dedicated connectors and how they share this pipeline.
• Traffic-driven discovery — what happens to ingested traffic downstream.
• Learned examples — how captured payloads become mapping evidence.

---

All Specaria SOAP to REST docs