SOAP-to-REST release notes

Overview

Version 1.7.32 is a patch release that addresses stability and deployment issues. This release resolves a critical startup failure in administrative services and corrects a permission misconfiguration that affected product updates for ingest services.

Fixed

This release includes the following fixes:

• A database migration issue that caused administrative services to fail and enter a crash loop during startup has been resolved. The failure was due to parameter permission errors and was observed in over 15 environments.
• Deployment permission settings have been corrected. This fix allows release controllers to successfully manage and update ingest services during product updates.

This release introduces more robust system update logic, improves browser compatibility for administrative actions, and resolves issues related to system status reporting and registration authentication.

New Features

Multi-Component Version Skew Detection

System updates now automatically evaluate the versions of all deployed services instead of relying on a single service's version. Update processes will trigger based on the lowest version found among all running components. This ensures that deployments with out-of-date services are correctly identified and fully converged to the target version.

Changes

Cross-Site Request Forgery (CSRF) Browser Compatibility

The administration console's mechanism for validating same-origin requests has been updated to use the browser-native Sec-Fetch-Site metadata header. This change improves compatibility and prevents the system from incorrectly blocking valid administrative actions.

Previously, actions such as testing operations, importing WSDL files, and previewing SOAP-to-JSON transformations could be blocked if different system components were running on different patch versions. This change resolves that issue.

Fixes

This release includes the following fixes:

• System Heartbeat Claims: System heartbeat sender claims are now correctly scoped and executed using dedicated database permissions. This fix ensures that administrative interfaces reliably display the correct system status and updates, particularly in multi-tenant deployments.

• Registration Authentication: Product registration requests now correctly send the deployment authorization header when an active installation secret is present. This prevents the system from generating false authentication alerts during service restarts.

This release introduces support for automatic self-updates and includes fixes to improve the reliability of installation secrets and database connectivity.

New Features

Automatic Self-Updates

Controller releases now embed release-manifest verification keys. This enables the system to perform automatic self-updates, streamlining the application of future product releases.

Fixes and Improvements

Installation Secret Persistence

The reliability of installation secrets has been improved. When a database is connected, these secrets are now persisted to durable storage. This prevents the loss of state during system restarts and ensures continuous access to deployment channels.

Database Schema Detection

The system can now automatically detect when required database schemas are missing. If a schema is not found, the system issues a status warning and gracefully retries its connection checks. This behavior prevents system lockouts and allows an operator to apply the necessary schema updates without a hard failure.

This release provides a fix for an authentication issue that affected administrators in specific network configurations.

Fixes

This release resolves the following issue:

• Authentication Failures Behind Regional Load Balancers: An issue was fixed that prevented administrators from authenticating to the platform. This issue occurred on deployments hosted behind a regional load balancer and could cause "unauthorized" errors when an administrator attempted to access the application or accept terms of service.

New Features

Per-Install Deployment Secret Management

This release adds automatic registration, persistence, and verification of unique deployment secrets for each installation. The status and verification results of these secrets can be inspected through system status endpoints.

Ingest Path Hardening

Public generic ingest endpoints now support optional IP allow-listing and rate-limiting parameters.

• Requests originating from IP addresses outside the configured allow-list will be rejected with a 403 Forbidden status.
• Requests that exceed the configured rate limits will be rejected with a 429 Too Many Requests status.

Comprehensive Audit Logging

The audit logging system has been expanded to include more security-sensitive events:

• Registration and deletion of load balancer connector credentials.
• Updates to syslog configurations.
• Changes to the support consent break-glass state (enabling or disabling temporary support access).

Database Row-Level Security (RLS) for Runtime Operations

For multi-tenant deployments, runtime database connections now use an isolated database application role to enforce PostgreSQL Row-Level Security (RLS), ensuring stricter data isolation between tenants.

Changes and Improvements

Role-Based Access Control & Minimum Permissions

• The administrative user interface has been updated to align directly with backend role requirements. UI controls for settings are now rendered as read-only for users who do not have the required role for editing.
• The Developer role is now strictly required for the following actions:
  • Editing whole mappings.
  • Regenerating mappings at the operation or service level.
  • Synthesizing version mappings.
• Unlisted administrative write endpoints (POST, PUT, PATCH, DELETE) now require the Admin role by default, unless a different role is explicitly configured.

Asynchronous Execution & Callbacks

• Asynchronous callbacks now enforce single-completion behavior. If a secondary or conflicting completion attempt is made for a callback that has already completed, the system will respond with a 409 Conflict status.
• Callback authentication secrets are now write-only in administrative interfaces and API responses. The system will only indicate whether a secret is set, without exposing the secret itself.

Strict Identity & Security Hardening

• Authentication: Plain-identity authentication headers, intended for development, are now strictly prohibited in deployed services or when an external Identity Provider is active.
• Multi-Tenancy:
  • Tenant prefixing for external Identity Providers is now restricted to an explicitly configured list of trusted external tenants with verified emails.
  • In multi-tenant mode, unbound requests are now rejected with a 401 Unauthorized status instead of defaulting to a shared tenant context.
• Authorization:
  • Path-based authorization checks now resolve canonical, parsed paths (handling URL-encoding and parameters) to prevent path-traversal and authorization-bypass vulnerabilities.
  • To mitigate Cross-Site Request Forgery (CSRF) attacks, form posts and administrative write operations now require an X-Requested-With header.
• Credential Management:
  • When changing a stored credential's target or disabling a security check (e.g., SSL certificate verification), the user must re-enter the stored credentials for verification.
  • Restrictive host headers are no longer included in outgoing profile headers.

Sensitive Data Masking

• The X-S2R-Tenant-Key header is now automatically redacted from request logs and outgoing gateway calls.
• For requests that are rejected with a 413 Payload Too Large status, sensitive header values are stripped from the oversized request payload traces.
• Audit logging for updates, connectors, and system health now extracts actor details exclusively from the verified token context, rather than relying on unverified request headers.

Fixes

Database Migration Reliability

An issue was resolved where database schema validation could fail at startup. The system now automatically performs checksum healing for legacy database migration history entries (V256) that previously differed only in comment formatting.

Update Reconciliation Tracking

The system's ability to track the live status of background updates has been improved.

• Completed update attempts now clear their "in-progress" status immediately upon a status check.
• Client attempt IDs are now generated reliably before an update is triggered.

Version 1.7.27 introduces significant enhancements to license handling, data security, and service reliability, along with several targeted fixes. Key additions include automated platform license verification and stricter tenant data isolation.

Added

• Platform License Verification: License verification for self-ID licenses is now automated. The platform uses its public JWKS endpoint to validate licenses, removing the need for API publishers to manually provide keys. For resilience against temporary network issues, keys are cached locally with fallback support.
• Relay Deployment Configuration Parameters: New script parameters have been added to configure and persist settings for relay deployments across automated updates. These parameters control custom batch sizes, throughput windows, and TCP connection settings. The source does not specify the names of these parameters.

Changed

Admin UI and Layout

• Tables in the Admin UI for Onboarding, Observability, Settings, and Saved Scans have been updated to display multi-value list items as single-line entries. A (+N) badge indicates the number of additional items, preserving a consistent row height.
• Clicking on table rows in the Onboarding, Observability, and Settings sections now opens a unified modal overlay to display complete details, replacing the previous inline card expansion behavior.
• Redundant UI panels and styling have been removed from F5 Observability dashboards for a cleaner layout.

Strict Tenant Data Isolation

• System-wide tenant data isolation has been enforced by applying Row-Level Security (RLS) and strict tenant scoping. This change affects database operations, API endpoints, background jobs, and caching mechanisms.
• As a result of this change, any API request attempting to access a resource that is missing or belongs to another tenant will now receive a standard 404 Not Found response. This prevents leaking information about the existence of resources across tenants.
• Tenant-specific caches for authorization roles, administrative user modes, and configuration lookups are now cleared immediately upon an update. This ensures that permission changes take effect instantly, without waiting for a cache expiration timer.

Relay Ingestion and De-duplication

• To prevent duplicate event writes from network retries, ingestion requests now support a unique batch tracking identifier via the X-S2R-Batch-Id HTTP header.
• Batch processing logic has been improved to report success or failure metrics for individual events. This prevents an entire batch from failing if only a single record fails validation.
• The raw JSON log parser now correctly processes all concatenated JSON event payloads within a single ingestion request, preventing data loss from trailing events.

Relay Network and Service Reliability

• The network listener now proactively rejects excess TCP connections before they can allocate operating system execution threads, preventing resource exhaustion during traffic spikes.
• Throughput metric calculations in relay health endpoints have been corrected to measure initial connection attempts rather than deferred queue processing, providing a more accurate measure of service load.
• Service reconcile scripts now persist pending restart requests. This guarantees that configuration changes are applied even if a service unit fails to restart on the first attempt.
• Automated updates now include a step to automatically expand disk partitions for subvolume-based filesystem roots.

Deployment and Controller Integrity

• Deployment templates for release controller services are now configured with internal flush HMAC authentication.
• The application deployment sequence now includes a health verification step for new revisions. If a new service version fails to serve traffic, the deployment is automatically rolled back, and the previous version's labels are restored.
• The release controller's status reporting now includes its active build identifier.
• License entitlement fallbacks have been updated to handle channel access errors.

Fixed

• Connector Table Modal Error: Corrected an issue with broken element IDs in connector instance views that prevented delete confirmation modals from opening.
• Disruption-Free Reconciles: Fixed an issue where temporary catalog unavailability during F5 reconciliation could cause scopes to be cleared prematurely.
• Relay Dispatch Attribution: Resolved a bug in relay task dispatch handling to ensure execution results are correctly bound to the submitting relay instance.
• Certificate Upload Token Generation: Prevented command-line error messages from being included in the output of token generation during certificate uploads.

This release addresses an issue that caused excessive log generation during data ingestion.

Fixes

This release contains the following fix:

• Reduced System Log Noise and Disk Usage: Corrected an issue where expected XML parsing fallbacks during data ingestion generated a high volume of unformatted error messages in system logs. These diagnostic messages are now routed to debug-level logs. This change significantly reduces unnecessary log volume and helps prevent potential disk space exhaustion.

This release provides a significant improvement to the platform's syslog ingest performance.

Changes

Improved Syslog Ingest Throughput

Syslog ingest throughput has been significantly improved by introducing batching for log forwarding. The system now batches up to 100 messages together or sends one batch per request.

This change addresses an issue where messages could be dropped during periods of high traffic volume. By batching logs, the platform ensures that log discovery features receive accurate and complete traffic samples for analysis.

Version 1.7.24 introduces enhancements focused on the stability, management, and self-healing capabilities of syslog relay instances. Key improvements include automatic updates for relay configurations, better disk and connection management, and fixes for issues related to disk saturation and component cleanup during updates.

Added

• Automatic Relay Script Updates: Relay instances now support live self-healing. Startup scripts and VM configuration files are automatically delivered and updated on deployed instances as part of product releases, ensuring they are always current.
• Configurable TCP Limit Options: New configurable settings have been added for managing syslog relay connections. The source specifies two settings with default values of 2048 and 900.

Changed

• Filesystem-Aware Volume Resizing: The disk auto-extension mechanism on syslog relay instances has been improved. It now automatically detects the underlying filesystem format and uses the correct utility for resizing. Supported filesystems include ext2/3/4, XFS, and btrfs.
• Enforced Relay TCP Connection Limits: File descriptor limits and connection thresholds are now implemented on syslog relay instances. This change prevents uncontrolled growth in connections and processes, improving instance stability.

Fixed

• Relay VM Disk Outages: Resolved an issue where unmanaged growth of container logs could fill the primary system drive on relay instances, which would halt message forwarding.
• Legacy Relay Cleanup: During system updates, legacy relay components and containers are now safely stopped and removed. This prevents port conflicts and unmanaged disk usage from old components.
• Database Migration Compatibility: An issue with deployment validation errors during system updates has been fixed by restoring migration file integrity checks.

Version 1.7.23

This release provides a performance improvement for the user interface.

Fixed

• The performance of the service details view, located under Observability → Discovered Traffic, has been significantly improved. Previously, this view could experience long load times or time out. With this fix, the main service information now loads almost instantly, and the Recent Failures list loads asynchronously without blocking the rest of the page from rendering.

This document provides the release notes for version 1.7.22.

Fixes

This release includes a fix to the product upgrade process.

• Automated F5 BIG-IP Rule Updates: Product upgrades now automatically update the necessary traffic management rules on your F5 BIG-IP appliance. This automation removes a manual step that was previously required after an upgrade. It ensures that subsequent fixes, such as one to correctly log the URI for all requests, are applied reliably.

Summary

Version 1.7.21 introduces documentation for the SOAP Broker feature and includes performance enhancements for traffic data processing.

Added

SOAP Broker Documentation

New documentation is now available for the SOAP Broker feature. This guide explains how to configure the system to function as a pass-through broker for backend SOAP services. Utilizing the broker provides benefits such as traffic logging, per-operation metrics, and usage analytics without requiring modifications to the backend service.

Changed

Traffic Data Processing Efficiency

The efficiency of traffic data processing has been improved to better manage high volumes of API calls. This change increases the reliability of data handling under heavy load.

See Also

• SOAP Broker: A guide to configuring the platform as a pass-through broker for SOAP services.

This release addresses issues related to service onboarding and SOAP API call identification.

Fixes

This version includes the following fixes:

• Service Onboarding Validation: The system now correctly generates example values for API definition fields that specify both a regular expression pattern and a length limit. Previously, this combination could lead to a validation error that blocked the service onboarding process, even with a valid API definition.

• SOAP API Identification: The reliability of identifying SOAP API calls has been improved. The system now uses the SOAPAction header to determine the specific operation name for an incoming SOAP request.

Summary

Version 1.7.19 improves the accuracy of the service inventory by refining the discovery process and corrects a display issue for certain services.

Changes

• More Accurate Service Inventory: The service discovery process has been updated to no longer create inventory entries for application parent paths that do not handle traffic directly. This change removes zero-traffic entries from the inventory, providing a less cluttered view that focuses on active services processing requests.

Fixes

• Corrected an issue where many services, particularly those using SOAP, would incorrectly display zero.

Summary

Version 1.7.18 introduces fixes for service discovery and the generation of example values in API specifications. Service discovery now correctly aggregates endpoints that use path parameters, and generated examples now conform to their defined schema constraints.

Fixes

This section details the fixes included in the v1.7.18 release.

Service Discovery Grouping for Path Parameters

Service discovery now correctly groups API calls with different path parameters into a single logical service.

Previously, requests made to endpoints with variable path parameters, such as /api/items/123 and /api/items/456, would result in the creation of separate, incomplete service entries. This behavior cluttered the service list and prevented traffic from being aggregated correctly for the logical endpoint.

With this fix, such requests are now correctly identified as belonging to the same service, ensuring a cleaner service list and accurate traffic aggregation.

Generated Specification Example Values

Example values included in generated API specifications now adhere to the constraints defined in their corresponding schemas.

Previously, generated examples might not have respected constraints such as maximum length, patterns, or enumerated values. This could produce invalid examples that would be rejected by API gateways or other validation tools. This fix ensures all generated examples are valid according to their schema definitions.

This release provides a fix for the syslog relay component.

Fixed

This release corrects an issue with the automatic disk expansion feature of the syslog relay.

• Syslog Relay Disk Expansion: The syslog relay will now automatically expand its disk storage when it begins to run low on space. This mechanism improves the reliability of traffic data collection by preventing interruptions or data loss that could occur if the disk became full.

Summary of Changes

Version 1.7.16 expands the functionality of the service examples feature and improves the reliability of data collection.

New Features

Expanded Transaction Examples

The "Examples" tab for a discovered service now generates representative transaction examples for a broader range of service types. Previously, this feature was limited to SOAP services.

With this update, examples are also generated for:

• RESTful services, including GET requests that do not have a message body.
• Services that use plain XML payloads.

This enhancement provides more comprehensive and useful examples for API publishers and consumers analyzing service traffic.

Fixes

Data Collection Reliability

This release resolves an issue where data collection could stop without warning if the system's disk became full. The system now includes automatic log file size management and will expand its disk capacity if necessary. This prevents service interruptions caused by disk space exhaustion and ensures more reliable operation.

Overview

Version 1.7.15 is a patch release that addresses a critical issue in the WSDL-to-mapping regeneration process. This fix ensures that API contracts derived from WSDLs with external schema imports are preserved correctly, preventing the accidental removal of validation rules.

Fixed

This release contains a fix for an issue where regenerating a mapping from a WSDL file could lead to the loss of data validation rules.

WSDL Regeneration Preserves Imported Schema Validations

Previously, when an API publisher regenerated a mapping from a WSDL file that used <import> to include type definitions from external schema files, the process could silently strip validation rules from the mapping. This affected rules such as string length, numeric ranges, and character patterns defined in the external schemas.

The consequences of this issue included:

• Incorrect Request Validation: Incoming requests might pass validation when they should have failed, potentially leading to errors in backend services.
• Activation Failure: The affected API version might fail to activate due to the inconsistent or incomplete contract.

This has been resolved. The regeneration process now correctly parses and preserves all type definitions and their associated validation rules from imported schemas.

Additionally, a new safeguard has been introduced. The system now prevents an existing mapping from being overwritten if the regenerated version is less detailed than the current one. This protects against the accidental degradation of an API contract during regeneration.

Summary

Version 1.7.7 introduces a new SOAP Broker mode for handling legacy SOAP integrations and an associated access control mechanism based on consumer IP addresses.

New Features

This release adds the following capabilities.

SOAP Broker Mode

A new "SOAP Broker" mode is now available. This mode provides transparent, byte-faithful SOAP-to-SOAP passthrough. It is designed for legacy integrations where preserving the integrity of the original XML payload is critical.

SOAP Broker Access Control

To secure services operating in SOAP Broker mode, this release adds IP-as-credential access control. API publishers can create grants that restrict service access to a list of authorized API consumer IP addresses.

This release improves the reliability and functionality of the "Bulk Apply" feature for HTTP profiles.

Feature Enhancements

Bulk Apply for HTTP Profiles

The "Bulk Apply" feature, used for assigning HTTP profiles to multiple virtual servers, has been updated to be more powerful and reliable.

The key changes are:

• Handling of Existing Profiles: Previously, attempting to apply an HTTP profile to a virtual server that already had one would cause an error. The feature will now automatically replace any existing HTTP profiles on the target virtual servers.

• Batch Processing on Failure: Previously, a failure on a single virtual server could halt the entire batch operation. Now, if an update for a single server fails, the process will continue with the remaining servers in the batch.

• Detailed Reporting: After the operation completes, the system now provides a detailed summary report. This report includes a list of successes, failures, and any items that were skipped.

This document provides the release notes for version 1.7.5 of the s2r platform.

Summary of Changes

This release introduces a quality-of-life improvement for managing F5 virtual servers by allowing bulk role assignment. It also includes a fix to ensure that multiple selected virtual servers are correctly added to the discovery scope when saved.

New Features

Bulk Role Assignment for F5 Discovery

On the F5 Discovery settings page, API publishers can now assign a role to multiple virtual servers simultaneously. This feature streamlines the configuration of large numbers of servers.

To use this feature:

1. Navigate to the F5 Discovery settings page.
2. Select the checkboxes for the desired virtual servers.
3. Open the Bulk Apply menu.
4. Choose the Set role option.
5. Assign one of the following roles:
   • Frontend
   • Backend
   • Remove from scope (by selecting the option to remove)

Fixes

F5 Discovery Scope Saving

Previously, when an operator selected multiple virtual servers on the F5 Discovery settings page and clicked Save Scope, the selected servers were not added to the discovery scope. This issue has been resolved. Now, any servers selected in the UI are correctly added to the scope upon saving.

This document provides the release notes for version 1.7.4.

Added

• Service Inventory Traffic Summary: The Service Inventory table on the Discovery page now features a summary row at the bottom. This row displays the total number of observed API calls across all services for the 24-hour, 7-day, and 1-month time periods, providing an at-a-glance view of total API traffic volume.

Changed

• The Ingest VM health status

This release introduces more detailed information for available product updates, improves the accuracy of update status reporting, and corrects the behavior of the Manual SOAP Test during API onboarding.

New Features

Enhanced Update Information

The Available update card on the Settings > Updates page now provides more context for new product versions before installation. The card displays the following additional information:

• Severity: The severity level of the update.
• Summary: A brief summary of the changes in the update.
• Release Notes Link: A direct link to the release notes for the new version.

This allows administrators to better assess the impact and importance of an update before applying it.

Changes and Improvements

Accurate Update Status Reporting

The update status check on the Settings > Updates page now provides more precise feedback. Previously, if an update check failed (for example, due to a network issue), the UI could incorrectly display an "Up to date" status.

With this change, the UI will now report the specific reason why the update check could not be completed, ensuring administrators have an accurate understanding of the system's update status.

Fixes

Correct SOAP Fault Handling in Manual Tests

During API onboarding, the Manual SOAP Test will now correctly report a failure when a backend service responds with a SOAP Fault message. In previous versions, tests that received a SOAP Fault could be incorrectly marked as successful. This fix prevents misconfigured APIs from appearing to be functional during the onboarding process, ensuring that only correctly configured backend services pass the test.

Overview

Version 1.7.2 introduces user interface enhancements to the administration console and resolves a critical issue related to system updates. The changes improve usability on wide-screen displays by increasing the maximum page width and rebalancing column sizes on the Services page. This release also fixes a silent failure mode where the system would not apply updates while incorrectly reporting that it was up to date.

Changes

This release includes the following enhancements to the administration console user interface:

• Increased Page Width: The maximum width of pages has been increased. This change makes better use of available screen space on wide monitors, providing more room for content within tables.
• Improved Services Page Layout: On the Services page, the column widths have been adjusted to improve readability. Specifically, the Service URL Name and Display Name columns are now wider to reduce text truncation, making it easier to identify services.

Fixes

This release resolves a significant issue with the system update process:

• Update Status Reporting: Previously, the system could fail to apply an update, but the administration console would incorrectly report the status as "Up to date". This issue has been fixed. The console will now accurately reflect when an update check fails. The underlying cause of these silent update failures has also been resolved to ensure updates are applied correctly.