Docs Public Knowledgebase Releases V1 0 Ga

Overview

The SOAP-2-REST v1.0 platform is the inaugural General Availability release for converting traffic between SOAP and REST APIs. It is a self-hosted solution that runs entirely within an organization's VPC, designed to help API publishers modernize legacy SOAP services and enable legacy clients to consume modern REST services.

The platform's core capabilities include:

• Bidirectional Conversion: The same runtime can act as a REST facade for a SOAP backend (Publish direction) or as a SOAP facade for a REST backend (Consume direction).
• Traffic-Driven Discovery: The platform can discover existing SOAP services by analyzing live traffic from various API gateways and load balancers.
• Contract Generation: It generates standards-compliant OpenAPI v3 specifications for published REST facades and serves WSDL contracts for consumed SOAP facades.
• Observability: It provides integrated dashboards, searchable logs, SLO reporting, and live traffic inspection.
• Security: The platform integrates with enterprise identity providers, encrypts credentials, and maintains a full audit trail, with no public-facing endpoints by default.

This document provides a comprehensive inventory of the features and capabilities included in the v1.0 release.

How it works

The platform's runtime engine performs deterministic, full-field conversion between SOAP/XML and REST/JSON payloads. The direction of conversion depends on the configured mode for a given service.

• Publish Direction: A REST facade is created for an existing SOAP backend service. The platform ingests a WSDL, generates a corresponding OpenAPI v3 specification, and exposes a REST/JSON endpoint. Incoming REST requests are converted to SOAP, sent to the backend, and the SOAP response is converted back to REST for the API consumer.
• Consume Direction: A SOAP facade is created for an existing REST backend service. The platform exposes a SOAP endpoint and serves a WSDL contract. Incoming SOAP requests are converted to REST/JSON, sent to the backend REST service, and the JSON response is converted back to a SOAP envelope for the API consumer.

The following diagram illustrates both data flows.

flowchart TD
    subgraph "Publish Direction: REST Facade for SOAP Backend"
        C1[API Consumer] -- 1. REST/JSON Request --> RT[SOAP-2-REST Runtime]
        RT -- 2. Converts to SOAP/XML --> RT
        RT -- 3. SOAP/XML Request --> BS[Backend SOAP Service]
        BS -- 4. SOAP/XML Response --> RT
        RT -- 5. Converts to REST/JSON --> RT
        RT -- 6. REST/JSON Response --> C1
        RT -.-> O((Generated OpenAPI v3))
    end

    subgraph "Consume Direction: SOAP Facade for REST Backend"
        C2[API Consumer] -- 1. SOAP/XML Request --> RT
        RT -- 2. Converts to REST/JSON --> RT
        RT -- 3. REST/JSON Request --> BR[Backend REST Service]
        BR -- 4. REST/JSON Response --> RT
        RT -- 5. Converts to SOAP/XML --> RT
        RT -- 6. SOAP/XML Response --> C2
        RT -.-> W((Served WSDL))
    end

Mappings are generated deterministically from the source WSDL/XSD and are stored as immutable, versioned snapshots that can be activated or rolled back. API publishers can apply field-level overrides to the generated mappings through the UI.

Onboarding a Service Example

The platform includes a "no-code WSDL onboarding wizard" to create and configure a new service. While the source does not provide a specific request/response example, it describes the following one-step autopilot process:

1. Import WSDL: Begin by importing a WSDL file. This can be done via file upload, a direct URL, or by pasting the raw XML content into the UI.
2. Initial Analysis: The platform analyzes the WSDL to infer a suggested backend endpoint, SOAP version, and authentication hints. It also performs "namespace repair" for syntactically broken WSDLs.
3. Autopilot Generation: Using the "zero-touch autopilot" feature, generate a draft service configuration. This single step creates the service, its operations, and the initial data mappings. The platform assigns a "readiness score" to each generated operation.
4. Review and Activate: Review the generated configuration, including sample payloads generated for each operation. Once satisfied, activate the service to begin routing traffic.

The platform also supports re-importing a WSDL to detect changes, such as added or removed operations and other breaking changes.

Feature Reference

Conversion Engine

The core of the platform is its bidirectional conversion engine, which supports a wide range of SOAP standards and provides extensive customization.

• Directions:
  • Publish: Converts incoming REST/JSON to outgoing SOAP/XML. The published contract is an OpenAPI v3 document.
  • Consume: Converts incoming SOAP/XML to outgoing REST/JSON. The published contract is a WSDL served by the runtime.
• SOAP Support:
  • SOAP 1.1 and 1.2, including the application/soap+xml content type and the two-level fault model of SOAP 1.2. The runtime automatically detects the version from the request body and Content-Type header.
  • WSDL message styles: document/literal (wrapped and bare) and rpc/literal.
• Mapping and Transformation:
  • Deterministic, full-field mapping generated from WSDL/XSD.
  • Mappings are immutable and versioned, with support for activation and rollback.
  • Field-by-field overrides can be configured in the UI.
  • SOAP faults are normalized into a deterministic REST error shape. WSDL-declared fault details are reflected in the generated OpenAPI schema.
  • Supports per-operation injection of SOAP headers.

Outbound REST Authentication (Consume Direction)

When acting as a SOAP facade for a REST backend, the runtime can authenticate to the upstream REST service using the following methods:

• None
• Basic Authentication
• Bearer Token
• OAuth2 Client Credentials
• API Key in Header
• Mutual TLS (mTLS)

Conversion Options

The platform provides a catalog of tunable behaviors that can be set globally and overridden at the service, operation, or field level.

Resilience and Performance

• Multi-Backend Routing: Configure multiple backend endpoints for a single service to enable failover.
• Health Checks: Actively monitors the health of backend services.
• Timeouts and Retries: Per-operation timeout and retry settings are configurable. The source specifies a default timeout of 100 ms and a default of 2 retries.
• Payload Size Limit: A hard ceiling of 30 MB is enforced for synchronous payloads. Requests exceeding this limit receive a "clear coded rejection."
• Performance Baseline: The platform is engineered and tested for a baseline of approximately 1 million calls per day (~12 rps sustained, ~100 rps burst).

Discovery and Onboarding

• Traffic-Driven Discovery: Automatically discovers services by analyzing live traffic from connected gateways and load balancers. The discovery view displays request counts over 24-hour, 7-day, and 1-month periods, loaded from pre-computed aggregation tables for fast performance.
• Consumer Attribution: Identifies API consumers by resolving IP addresses from headers such as X-Client-IP, X-Forwarded-For, and Forwarded.
• Learned Examples: Captures real request and response payloads and headers from production traffic, which can be curated and associated with specific services and operations.

Connectors

The v1.0 release includes connectors for traffic discovery and ingest from the following platforms.

Observability

• Operations Dashboard: Provides KPI tiles, timeline charts, and per-service rollups.
• SLO Reports: Allows configuration of availability and latency targets with breach detection.
• Searchable Logs: Runtime logs are searchable and keyed by correlation ID, result code, environment, service, and operation.
• Live Traffic: A live log viewer displays full request/response payloads and headers for detailed analysis.
• Contract Drift Detection: Monitors backend responses for deviations from the expected contract.
• Asynchronous Callback Tracking: Tracks the lifecycle and timing of asynchronous callbacks, with features for replaying stored callbacks, manual reprocessing, and overdue detection.
• Data Retention: Log and metric data is retained for a default of 60 days, which is configurable.

Security

• Role-Based Access Control (RBAC): Predefined roles (admin, operator, reader) can be mapped from an identity provider's groups, bound directly to principals in-app, or managed via an emergency bootstrap list.
• Identity Integration: Supports Google IAP, Azure AD, and standard SAML / OIDC for user authentication.
• Network Security: The platform has no public endpoint by default and is designed for internal-only networking.
• Credential Management: Backend credentials are encrypted using pgcrypto and are never logged or returned in plaintext. On Google Cloud, IAM database authentication is supported.
• Audit Trail: A full audit trail records all actions, including the actor, role, and the before/after state of the change.

Licensing

• Verification: The platform uses a JWKS-verified RS256 license JWT, which is re-verified periodically.
• Grace Period: An offline grace period of 14 days is provided before the platform enters a degraded (read-only) mode.
• Failure Modes:
  • Fail-open telemetry: An outage in telemetry reporting will not disrupt traffic.
  • Fail-closed entitlement: An invalid or expired license will disable licensed write operations after the grace period expires.
• Telemetry Data: Outbound telemetry consists only of numeric counts, versions, a hashed host fingerprint, an installation ID, a customer label, and a contact email. No PII, payloads, or hostnames are egressed.

Deployment

The platform can be deployed in several environments:

• Google Cloud: A native deployment using Cloud Run, Cloud SQL (PostgreSQL), Cloud Storage, and Cloud IAP. Also available via the GCP Marketplace.
• Kubernetes / OpenShift: A Helm chart is provided for deployment.
• Docker Compose: A standalone stack for the control plane, runtime, worker, and PostgreSQL is available.
• Cloud Adapters: An abstraction layer for cloud services (object store, compute, etc.) is included, with adapters for Google Cloud, Azure, and VMware. Sample Terraform environments are available for AWS, Azure, and a vSphere relay.

Known Limitations

The following capabilities are not included in the standard v1.0 product and are considered out of scope.

• RPC/encoded Messages: Only document/literal and rpc/literal SOAP message styles are supported.
• WS-Security: Inbound message signing/encryption for the Consume direction is not supported. Outbound REST authentication methods, including mTLS, are supported.
• Non-HTTP Transports: The platform only supports HTTP/HTTPS. Transports like message queues or SFTP are not supported.
• Air-Gapped Operation: The platform requires outbound HTTPS connectivity for licensing and updates. A 14-day offline grace period is provided for transient connectivity loss.
• Native Cloud Ports: VM appliance images and first-class native integrations for AWS, Azure, and Oracle are not part of v1.0.
• Additional IdPs and Connectors: Support for identity providers like Okta and Keycloak, and dedicated connectors for modern API management platforms, are not included in v1.0. The generic-HTTP receiver can be used as a workaround for the latter.

See Also

The source material for this document references the following related documentation pages:

• How mapping works
• Conversion options reference
• SOAP & XSD support
• Generate & review the OpenAPI
• Discovery
• Onboarding
• Connectors
• Observability
• Security
• Licensing
• Installation
• Operations
• Support lifecycle & deprecation policy
• Upgrade guide

All SOAP-to-REST docs