Licensing — overview
SOAP-2-REST by Specaria is licensed software. An installation's entitlement is expressed as a signed license issued by the Specaria platform, and the product…
What "licensed" means
SOAP-2-REST by Specaria is licensed software. An installation's entitlement is expressed as a signed license issued by the Specaria platform, and the product verifies that license against keys it fetches from the platform. The license is the source of truth for entitlement — the product never grants entitlement from local configuration alone.
The license carries:
- an expiry,
- a binding to this specific installation, and
- two capacity caps — how many services you may discover and how many you may run as converted/active services.
See License model for the full design, and Capacity counting for exactly how the two caps are measured.
At a glance
| Topic | Summary | Detail | |---|---|---| | License model | RS256-signed license as source of truth; verified against keys fetched from the Specaria platform; re-verified periodically | License model | | Capacity counting | Two dimensions — discovered services (no decay) and converted/active services (decays over a rolling 7-day window) | Capacity counting | | Offline grace | A bounded grace window when the platform is unreachable, then a degraded/read-only mode; telemetry fails open, entitlement fails closed | Offline grace | | Egress allow-list | Outbound HTTPS to the Specaria platform; metadata only, never payloads or PII | Egress allow-list |
Relationship to the earlier static-file model
An earlier, static-file licensing predecessor exists in the product's design history. In that model the public verification keys were bundled into the product binary at build time and the license was a file the operator uploaded; validation was fully offline with no platform contact.
The v1.0 Specaria-platform-integrated model supersedes that predecessor. Instead of bundling keys statically, v1.0 fetches verification keys from the platform (so keys can rotate without a product release) and adds periodic re-verification plus an optional capacity heartbeat. A bundled key still exists, but only as a bootstrap seed for the very first start before the platform has been reached — not as the long-term source of verification keys.
What the product does not do
By design, the v1.0 licensing model:
- does not send your SOAP payloads, backend hostnames, or any end-user PII to the Specaria platform — see Egress allow-list;
- does not require inbound connectivity — the Specaria platform never connects to your product; all calls are outbound from the product;
- does not stop existing runtime traffic the moment the platform becomes unreachable — there is a bounded offline grace window first. See Offline grace.