Purpose of This Document

This document describes the available endpoints, authentication requirements, expected responses, and recommended best practices for safely incorporating these checks into client-side monitoring workflows.

Who Can Use These Endpoints

Access to these endpoints for clients leveraging Unique SaaS is only available to Single Tenant clients.

For Self-Hosting clients the endpoints are naturally also available as described below but on their respective infrastructure.

Multi-Tenant SaaS clients cannot leverage the endpoints and they are protected by authentication.

Overview of Service Availability Endpoints

What Are Availability Endpoints?

Availability endpoints are lightweight URLs provided by Unique AI that allow clients to quickly verify whether their dedicated service instance is currently operational.

When to Use Them

Availability endpoints should be used whenever a client needs a quick and reliable way to confirm that their Unique AI service instance is reachable. They are ideal for basic uptime checks, automated monitoring systems, and alerts that notify teams when the service becomes unavailable.

Rate Limits & Fair-Use Guidelines

Availability endpoints are protected by web application firewalls configured with bot-protection rules, OWASP security standards, and automated traffic controls.

To ensure stability and security, clients should query these endpoints responsibly and avoid high-frequency or automated probing that resembles abusive traffic.

Excessive or suspicious request patterns may trigger temporary isolation by the firewall, which can also impact access to the service’s workloads. For this reason, clients are encouraged to follow fair-use practices and integrate the endpoints into monitoring systems with conservative polling intervals.

Authentication & Access Requirements

The availability endpoints do not require authentication and can be accessed directly. Adding authentication would defeat their purpose, as these endpoints are intended to provide a simple and fast way to confirm that a service instance is alive. They are instead protected by the previously mentioned web application firewalls, which enforce bot protection, OWASP rules, and potential IP-based blocking.

Clients who require authenticated or more advanced health-check mechanisms can consider upgrading to one of Unique AI’s self-hosting models, where such customization is fully supported.

Network Requirements (IP allowlisting, private endpoints, etc.)

Clients may optionally enable IP blocking or IP allowlisting to further restrict access to the availability endpoints. While this can enhance control, it may also affect business users and day-to-day operations if legitimate traffic is inadvertently blocked.

For this reason, IP-based restrictions should be applied carefully and only when there is a clear operational need.

Health Check Endpoints

Unique publishes a simple, best-effort CLI example to probe the endpoints.

The https://www.npmjs.com/package/@unique-ag/cli util:probe command can demonstratively assess the health of a given Unique tenant.

Endpoints

The endpoints always compose of:

• Domain {{domain}}: The domain your tenant is deployed to (always <tenant>.unique.app on Single Tenant environments) - Self hosting clients have their own domains.

• API Host {{apiHost}}: The host where your API Gateway is deployed, either gatewayor api.

Component

Note that not each component is needed/available for every client. Ensure you only monitor those that are available/deployed to your solution.

CLI Utility

qcli util probe <domain>

While the utility is is helpful, ultimately the endpoint list defines what shall be monitored. You can see the latest endpoints here: https://github.com/Unique-AG/cli/blob/92642008a1b75f80315622fa49827962673db59b/examples/util-probe.schema.yaml

npm install -g @unique-ag/cli
qcli --help
qcli util probe my-tenant.unique.app -c chat

╔════════════════════════════════════════════════════════════════╗
║  Checking Health Probes for my-tenant.unique.app (chat)        ║
╚════════════════════════════════════════════════════════════════╝

✓ [200] Admin App (https://my-tenant.unique.app/admin/health)
✓ [404] API Gateway (https://api.my-tenant.unique.app)
✓ [200] Chat API (https://api.my-tenant.unique.app/chat/probe)
✓ [200] Chat App (https://my-tenant.unique.app/chat/health)
✓ [200] Chat or Recording App (https://my-tenant.unique.app)
✓ [200] Configuration API (https://api.my-tenant.unique.app/configuration/probe)
✓ [200] Event Socket API (https://api.my-tenant.unique.app/event-socket/probe)
✓ [200] IDP Service (https://id.my-tenant.unique.app/debug/ready)
✓ [200] Scope Management API (https://api.my-tenant.unique.app/scope-management/probe)
✓ [200] Theme App (https://my-tenant.unique.app/theme/api/health)

──────────────────────────────────────────────────────────────────
✓ All 10 endpoints are healthy!

Monitoring Best Practices for Clients

Recommended Polling Frequency

For most use cases, a polling frequency of once every 30 to 60 seconds is sufficient to reliably detect availability issues without generating unnecessary traffic. Clients with less time-sensitive monitoring needs may choose longer intervals, while more aggressive polling is discouraged, as it may trigger firewall protections and provide little additional operational value.

Interpreting Response Data

Refer to Health Check Endpoints above.

Integrating with Monitoring Tools

When integrating availability endpoints with monitoring tools, clients should focus solely on the HTTP response code to determine service status. A successful response (typically 200 OK, can vary) indicates that the service is alive, while any other response code signals a potential issue. The endpoints do not provide detailed diagnostics or metrics, so monitoring should rely only on this simple status check.

Limits & Considerations

Cost

All requests to the availability endpoints generate ingress traffic on the application gateway, which may incur a minimal, marginal cost. While this cost is generally negligible, clients are advised to follow the recommended polling frequency of 30–60 seconds to avoid unnecessary traffic and ensure efficient use of resources.

What Endpoints Do Not Guarantee

These endpoints do not perform deep system diagnostics; instead, they return a simple response indicating whether the service is alive and reachable. This makes them ideal for basic uptime monitoring and integration with external monitoring tools, ensuring clients can immediately detect when their environment is online and available.

Security Considerations

No Sensitive Data Returned

The availability endpoints do not return any sensitive or client-specific data. Besides the HTTP response code indicating service status, the only additional information provided is the currently served application version. This allows clients to verify which version of the service is running without exposing any internal or confidential details.

Change Notifications for Clients

Additions to the endpoints can be identified through the Release Notes and Calendar, namely the Infrastructure Changesof an release.

Troubleshooting

Contacting Support

Refer to Enterprise Support