Going live

Work through this checklist before launching. XUND runs an acceptance test against your integration before production — the compliance items below are what it verifies. Each item names the rule; the linked Implementation Guidelines page has the details.

Compliance requirements

• Content integrity — API content (questions, options, descriptions, disclaimers, results) is shown unmodified, in the API's order. See Content integrity.
• Consent — the user explicitly accepts XUND's Terms of Use and Privacy Policy before any check feature. See Consent and imprint.
• Imprint — your legal notice names XUND Solutions GmbH as manufacturer with a "Powered by XUND" mark, rendered dynamically from the imprint endpoint. See Consent and imprint.
• Overview screen — the overview is displayed before it is confirmed, and the user can add, edit, and remove symptoms from it. See Checkflow rules.
• Disclaimers — any legal data the API returns is displayed and explicitly acknowledged. See Checkflow rules.
• Warning signs — shown immediately when triggered mid-flow, and again in the final report. See Checkflow rules.
• Back navigation — the user can step back to review or change earlier answers. See Checkflow rules.
• Age-gating — your app collects age and gates access below 16; the API does not enforce this. See Age-gating.

Operational readiness

• Token expiry handled — tokens expire and there is no refresh-token flow, and the token response carries no expires_in; your code either decodes the JWT's exp claim to refresh proactively, or requests a new token when a request comes back 401. See Authentication.
• checkId stored — it is the only handle on a check session; if you need to resume a check or link it to your own user records, you must persist it yourself. See API Concept.
• Inactivity closure accounted for — a check with no activity for 48 hours is closed automatically; after that, write endpoints reject it with 403 (CHECK_IS_FINISHED), while the history endpoints still serve it. Each interaction resets the window, so don't build resume-later UX that expects a check to survive more than ~48 hours idle.
• Error handling in place — your integration recognizes the API's error codes and recovers or surfaces them sensibly. See the Error handling guide.
• Language coverage decided — you know which language values your product sends, and every check-flow call sends one consistently. Content is fully finalized in en, de, and de-formal; for any other language, confirm coverage with XUND before launch.
• Test traffic flagged — automated tests and staging environments send "isCreatedByAutotest": true in the initialize body, so test runs don't pollute XUND's analytics. See Your first check.
• Request volume kept sensible — there are currently no documented per-partner rate limits, but design your integration to avoid unnecessary bursts (debounce optionSearchTerm lookups, don't poll endpoints in tight loops); fair-use controls may exist at the network edge.
• Report notifications considered (optional) — report and emergency-termination notifications are available via webhooks, set up by XUND on request. See the Webhooks guide.

Staying current

• Release notes monitored — someone on your team follows the Changelog & Policies page for release notes and the breaking change policy.