Status & Versioning

Wo Sie den Health-Status der xander API einsehen und wie wir Änderungen am API-Surface aktuell behandeln.

Service-Status

Die Live-Verfügbarkeit der xander API ist auf unserer öffentlichen UptimeRobot-Statusseite einsehbar:

https://stats.uptimerobot.com/GucIP5nVlb

Bookmark it in your browser and link it from your own internal monitoring dashboards. If your application is seeing failures, the status page is the first place to check whether the issue is on our side or yours.

Maintenance windows

We do not currently operate fixed maintenance windows. Planned interventions, when they happen, are coordinated individually with affected customers via your xander contact at XWare Pulse. If a planned maintenance is scheduled and might affect your workload, you will be notified in advance, you do not need to monitor a calendar.

Reporting an incident

If you observe a problem that is not yet reflected on the status page, please contact your xander contact at XWare Pulse, or write to xander@xwr.ch. Including the following in your message helps us debug faster:

The approximate time the problem started (with timezone).
The HTTP status code and full response body you received.
The UseCaseSessionId you set in Options.SessionMetadata , this is our correlation key into your specific calls.
The Client ID of the Service Principal you used (never the secret).
Whether the issue is happening on every call or intermittently.

API versioning

The xander API is currently at v1. The version is implicit, there is no /v1/ prefix in the URL path today and no API-Version header. All endpoints documented in the API Reference belong to this single, current version.

Breaking-change policy

We are deliberately conservative about changing the API surface in ways that could break existing client code. The current working policy is:

Additive changes (new endpoints, new optional request fields, new fields in response objects) are released regularly without prior notice. Your client code should be tolerant of unknown fields in JSON responses, this is standard JSON client hygiene anyway.
Breaking changes (removed endpoints, removed fields, renamed fields, changed field types, semantic changes) are announced in advance via your xander contact at XWare Pulse with a reasonable lead time before the change goes live. You will not be surprised by a breaking change in production.
If a breaking change cannot be avoided for technical reasons (e.g. a downstream provider deprecation forces our hand), we will work with affected customers directly to plan the migration.

Heads up: this policy is being formalised

We are actively working on a more formal versioning policy with concrete lead times, a published changelog feed, and a clear definition of what counts as a breaking change versus an additive change. Until that is in place, the practical guarantee is the one above: breaking changes go through your xander contact with personal advance notice. If you have specific requirements about how you'd like to be notified (email, RSS, webhook, …), let us know, we are designing the mechanism around customer needs.

Changelog

We do not currently publish a changelog feed in this portal. Material changes to the API are communicated to affected customers via your xander contact. As part of formalising the versioning policy above, a public changelog page is on our roadmap.

Where to go for more

For limits and rate-limit handling, see Limits & Quotas.
For getting started and authentication, see Onboarding.
For typical end-to-end workflows, see Cookbook.
For everything else, contact your xander contact at XWare Pulse, or write to xander@xwr.ch.