Configure the backend

A service's backend profile tells the runtime where to send the converted call and how to authenticate to it.

A service's backend profile tells the runtime where to send the converted call and how to authenticate to it. For a Publish service the backend is your SOAP service; for a Consume service the backend is your migrated REST service (see Consume direction for the REST-backend specifics).

Backend settings live under Services → your service → Backend. The WSDL import pre-fills an inferred endpoint and SOAP version — confirm and complete it here.

Core settings

| Setting | What it does | |---|---| | Endpoint URL | The backend address the runtime calls. Inferred from the WSDL soap:address on import; editable. | | SOAP version | SOAP 1.1 or SOAP 1.2. Detected from the binding on import. Since v1.0 the runtime also detects the version on the wire from body + content type. | | Transport settings | Per-backend SOAP transport (content type, SOAPAction handling). | | Timeout | Per-operation request timeout. Default 100 ms. Increase carefully — slow backends amplify under retry. | | Retries | Per-operation retry count. Default 2. |

The 100 ms / 2-retry defaults come from system settings and apply to every generated operation unless overridden per operation.

Authentication types

Since v1.0 the following outbound auth types are supported on the backend profile:

| Auth type | Use it for | |---|---| | none | Unauthenticated backends (e.g. inside a trusted segment). | | basic | HTTP Basic — username + password. | | bearer | A static or externally-provisioned bearer token. | | oauth2_client_credentials | OAuth2 client-credentials grant — the runtime mints and caches the access token. | | api_key_header | An API key passed in a named HTTP header. | | mTLS | Mutual TLS with a client certificate, composed alongside any of the above (mtls_enabled=true). |

Encrypted credentials

Backend credentials are encrypted at rest (pgcrypto) and are never logged or returned in plaintext. The encryption key is an operator-critical secret bound at deploy time; see Security → Backend credential encryption. Use the test connection action to validate the endpoint and auth before relying on it for a publish gate.

Multi-backend routing, failover & health checks

A single service can be backed by more than one backend. Since v1.0 the profile supports:

Multi-backend routing — register multiple backends for the service, with one designated as the default.
Failover — when the primary backend is unavailable, the runtime fails over to the next configured backend within the operation's bounded failure behavior.
Backend health checks — periodic health probes inform routing so failing backends are avoided.
Per-backend transport — each backend can carry its own SOAP transport and auth settings, so you can front a primary and a fallback that differ in endpoint or credentials.

Configure additional backends and the failover order under Services → your service → Backend.

Timeout & retry tuning

The defaults (100 ms / 2 retries) suit fast in-VPC backends.
Override per operation when a specific operation is legitimately slower.
Failure behavior is bounded — retries do not run unbounded, and the synchronous payload ceiling is 30 MB (oversized requests are rejected with HTTP 413 / S2R-RUN-0413).

The configured timeout/retry policy participates in publish readiness indirectly through the SOAP test — a backend that can't be reached with the configured auth and timeout will fail the test and block publish until corrected. See Publish & version a service.

Next steps

Generate & review the OpenAPI
Publish & version a service
Conversion options reference — upstream-failure-status controls the HTTP status a backend failure surfaces as.

All Specaria SOAP to REST docs

Loading…