Egress allow-list

The product runs inside your VPC and exposes no public endpoint. Its only outbound communication is to the Specaria platform, over HTTPS.

The product runs inside your VPC and exposes no public endpoint. Its only outbound communication is to the Specaria platform, over HTTPS. This page lists the endpoints your firewall must permit and states precisely what is, and is not, sent.

A foundational rule: the Specaria platform never initiates a connection to your product. All integration is outbound from the product over public HTTPS (TLS 1.3+). There is no inbound dependency.

Firewall egress to permit (outbound TCP 443)

Your VPC firewall must allow outbound HTTPS from the product subnet to the hosts below. Only one of them — api.specaria.io — is called by the product backend; the rest are reached only by an operator's browser.

| Host | Called by | Purpose | |---|---|---| | api.specaria.io | Product backend | All product↔platform integration: fetching license verification keys (JWKS), the capacity heartbeat, license-request submission, update notifications, feedback, and the build-time doc-upload pipeline. | | portal.specaria.io | Operator browser | Operator portal; support-chat surface. | | docs.specaria.io | Operator browser | Product documentation. | | doc-chat.specaria.io | Operator browser | In-product documentation help. | | status.specaria.io | Operator browser | Platform status page. | | www.specaria.io | Operator browser | Product marketing pages. |

Minimum to start. The product backend only needs api.specaria.io reachable on first cold start (to fetch verification keys) and thereafter within the offline grace window. The portal/docs/doc-chat/status/www hosts are browser-only convenience surfaces — the product backend does not call them.

Behind a corporate proxy

If your environment routes outbound traffic through an HTTP/HTTPS proxy, the product honours the standard proxy environment variables (HTTPS_PROXY, NO_PROXY) and a custom CA trust bundle (SSL_CERT_FILE). Proxy credentials in those variables are redacted from logs.

What is sent — and what is never sent

The data the product sends to the Specaria platform is strictly metadata. It is designed so that nothing about your traffic, your backends, or your people can leak.

Allowed in outbound payloads

Numeric counts — for example the capacity counts (discovered / converted services). Numbers only.
Versions — product version, agent version, build commit.
A hashed host fingerprint — a SHA-256 hash of a hostname, never the hostname itself.
An installation ID — an opaque UUID identifying this install; not customer-traceable on its own.
A customer label — a free-text identifier for the customer (informational).
A contact email — used only for license-request submission and as the license's "issued-to" contact.

Never sent

SOAP message bodies, request payloads, or response payloads — none of your traffic content ever leaves your network.
Backend hostnames, internal IPs, or service names — these would reveal your architecture, so they are never sent (the host fingerprint is hashed precisely so the raw hostname does not leave).
End-user names, emails, IDs, or any other PII.
Service display names / aliases (including Hebrew customer labels) — treated as customer business data.
Secrets, service-account keys, or environment-variable dumps.
Source code or configuration files.

The product is designed to route every outbound payload through a redaction step so that only the allowed shapes above can reach the platform; anything outside the whitelist is withheld.

The v1.0 design includes an operator-facing view of what each outbound signal contains, so the data leaving your network is inspectable rather than opaque. Combined with the allow-list above, the intent is that an operator can see — and a firewall can constrain — exactly what the product talks to and what it says.

Relationship to data residency

Because outbound traffic is metadata-only and inbound dependency is nil, your actual data — traffic, payloads, logs, the metadata database — stays entirely in your VPC. See Network & data residency for the full picture of where data lives.

All Specaria SOAP to REST docs

Loading…

Firewall egress to permit (outbound TCP 443)

Minimum to start. The product backend only needs api.specaria.io reachable on first cold start (to fetch verification keys) and thereafter within the offline grace window. The portal/docs/doc-chat/status/www hosts are browser-only convenience surfaces — the product backend does not call them.

Behind a corporate proxy

What is sent — and what is never sent

The data the product sends to the Specaria platform is strictly metadata. It is designed so that nothing about your traffic, your backends, or your people can leak.

Allowed in outbound payloads

Numeric counts — for example the capacity counts (discovered / converted services). Numbers only.

Versions — product version, agent version, build commit.

A hashed host fingerprint — a SHA-256 hash of a hostname, never the hostname itself.

An installation ID — an opaque UUID identifying this install; not customer-traceable on its own.

A customer label — a free-text identifier for the customer (informational).

A contact email — used only for license-request submission and as the license's "issued-to" contact.

Never sent

SOAP message bodies, request payloads, or response payloads — none of your traffic content ever leaves your network.

Backend hostnames, internal IPs, or service names — these would reveal your architecture, so they are never sent (the host fingerprint is hashed precisely so the raw hostname does not leave).

End-user names, emails, IDs, or any other PII.

Service display names / aliases (including Hebrew customer labels) — treated as customer business data.

Secrets, service-account keys, or environment-variable dumps.

Source code or configuration files.

The product is designed to route every outbound payload through a redaction step so that only the allowed shapes above can reach the platform; anything outside the whitelist is withheld.

Consent and transparency