Introduction

SOAP-2-REST by Specaria (short name Specaria S2R; product id s2r) converts between SOAP and REST in both directions, inside your own VPC, with deterministic…

SOAP-2-REST by Specaria (short name Specaria S2R; product id s2r) converts between SOAP and REST in both directions, inside your own VPC, with deterministic full-field mapping generated from your contracts and in-app observability on day one. It runs alongside your existing SOAP estate and your existing gateway — it does not replace either.

Since v1.0 the product is at General Availability. See the v1.0 GA release notes for the full feature inventory.

What it is

Most organizations run a SOAP estate built over many years — potentially hundreds of services and thousands of operations, with deep operational and regulatory dependencies. Modern consumers (mobile apps, partner integrations, SDK clients, AI agents) expect REST and OpenAPI; some legacy clients still expect SOAP even after a backend has moved to REST. SOAP-2-REST sits exactly on that boundary and bridges it automatically.

For each service it generates a deterministic, full-field mapping from the contract — every element, attribute, and optional field is covered, not just the common path. There is no proprietary transformation language to learn and no per-service scripting. When a business rule needs it, you override field-by-field in the UI. Mappings are versioned and immutable, with one-click rollback.

The Publish / Consume model

The product runs both directions of the SOAP↔REST boundary on the same runtime. Which direction a service uses is a property of that service.

Publish — REST facade over a SOAP backend

A modern REST/JSON consumer calls a generated REST API; the runtime converts the request to SOAP, calls your existing SOAP backend, and converts the SOAP response back to JSON.

Inbound contract: OpenAPI v3 (generated per service).
Backend: your existing SOAP service (unchanged).
Use it to: expose a legacy SOAP estate as clean REST for new consumers.

Consume — SOAP facade over a REST backend

A legacy SOAP client keeps speaking SOAP, but the backend behind it has already migrated to REST. The runtime accepts the inbound SOAP call, converts it to REST, calls the migrated REST backend, and wraps the REST response back into a SOAP envelope.

Inbound contract: WSDL (served back at the consume endpoint).
Backend: your migrated REST service.
Use it to: keep legacy SOAP clients working while you modernize the backend underneath them.

Both directions support SOAP 1.1 and SOAP 1.2 with full XSD coverage. Since v1.0 the runtime detects the SOAP version from the message body and content type.

See Core concepts → Publish vs Consume for the precise definitions, and the onboarding guide for how to set up each direction.

Where it sits in your stack

Your SOAP estate stays where it is. Your existing gateway or load balancer stays where it is, still doing authentication, rate-limiting, traffic management, and WAF. SOAP-2-REST sits alongside — listening to gateway-edge traffic for discovery, converting between SOAP and REST, and serving consumers — without modifying the upstream services.

[ SOAP estate ] → [ Gateway edge: F5 / DataPower / load balancer / generic HTTP feed ]
                          │
                          ▼
                  [ SOAP-2-REST by Specaria ]   (runs in your VPC)
                          │
                          ▼
                    [ REST consumers ]
        (mobile apps, partner integrations, SDK clients, AI agents)

The product is internal-only by design: there is no public endpoint. Access reaches it through your own network and gateway. Backend credentials are encrypted at rest and never logged or returned in plaintext. See Security → Network & data residency.

Who it's for

This documentation is written for the people who run the product:

Integration engineers / architects — onboard services, configure backends, tune conversion options, and review generated contracts.
Platform-engineering / SRE teams — deploy the stack, watch dashboards and SLOs, search logs by correlation ID, and respond to contract drift.
Security / identity teams — wire up RBAC and SSO (IAP / Azure AD / SAML / OIDC), manage credential encryption and retention.

The marketing-facing overview (audience: buyers and evaluators) lives in docs/marketing/product-overview.md. This KB is the operator-facing companion to it.

How the platform is structured

The product is a small set of services that all read from one PostgreSQL database (the source of truth for config and state):

| Component | Role | |---|---| | Admin API (control plane) | WSDL/OpenAPI import, CRUD, mapping generation, versioning, publish state. | | Runtime (data plane) | Handles production calls — converts SOAP↔REST, routes to the backend, emits metrics and audit events. | | Worker | Background jobs: discovery aggregation, learned-example curation, spec generation, alert evaluation. | | Admin UI | The no-code operator portal — onboarding wizard, dashboards, log search, audit. | | PostgreSQL | Metadata, mappings, versions, audit, aggregation tables. Tables are prefixed s2r_. |

Control plane and data plane are separate services so that operator activity never competes with production traffic.

Next reads

Core concepts — the vocabulary used throughout the UI and this KB.
Quickstart — get a published service running in minutes.
System requirements — confirm your host qualifies.

All Specaria SOAP to REST docs

Loading…