Launch

Move from staging to production traffic in one path: test, evaluate, review security and privacy, complete the checklist, then roll out in stages. Start with a staging token:

export DOCTRONIC_API_URL="https://staging-partners.doctronic.ai/api/v1"
export DOCTRONIC_API_TOKEN="replace-with-your-staging-token"
export DOCTRONIC_ENVIRONMENT="staging" # The SDKs read this instead of DOCTRONIC_API_URL.

Staging has its own credentials, users, and data. Ask your implementation contact which test data your staging integration may use.

Test in staging

Primary path

Run at least one complete consultation that:

1. Creates a user and stores data.id.
2. Creates a chat for that user.
3. Streams several patient turns, assembling content by messageId with the role from message.start.
4. Handles every control event separately from content.
5. Detects consultation completion only from ai_consultation.complete.
6. Retrieves each returned artifact ID, including through a 202 response.
7. Restores the displayed transcript from GET /chats/{chatId}/messages/.

Identity boundaries

Keep credential values out of test logs.

Stream parser

Feed your parser streams that split frames across network chunks, pack several frames into one chunk, include an unknown event name, end mid-frame, and contain an error event with retryAfterSeconds. Confirm frame order holds and an error event is handled apart from an HTTP error response.

Negative inputs

Send each of these and confirm your backend handles the 400:

• An invalid IANA timezone on chat creation or streaming.
• Context longer than 50,000 characters.
• Invalid pagination values.
• A malformed user field, such as an invalid email or date.
• A request body that doesn't match the OpenAPI schema.

Care workflows

If you offer appointments, test missing demographics, a missing or incomplete address, a chat that isn't ready for booking, no practitioners in the requested state, a slot that becomes unavailable (409), and an ASAP booking whose waiting-room URL is unavailable. When an error includes an appointmentId, retrieve the appointment before retrying. Cancel and reschedule from the latest appointment state.

For each booking, cancellation, and reschedule, repeat the request with the same Idempotency-Key and confirm Idempotency-Replayed: true, then change the body under the same key and confirm 409. See idempotent requests.

Webhooks

If webhooks are enabled, run the receiver tests against signed staging deliveries.

Evaluation

Doctronic runs evaluation and regression for the clinical system. You supply evidence that your integration works for the approved use case: identity mapping, context, event handling, routing, copy, and failure behavior.

Agree with Doctronic on:

• The patient population and use case, with in-scope and out-of-scope scenarios.
• Safety and escalation cases, and the expected dispositions and handoffs.
• The data and context available to the workflow.
• Acceptance criteria and required human review.
• The evidence required after a material model, prompt, workflow, or integration change.

Build a versioned test set from primary paths, uncommon but important presentations, ambiguous inputs, out-of-scope requests, safety conditions, incomplete patient data, and downstream failures. Record the API, workflow, and application versions behind each result. Automate repeatable contract, safety, and regression checks, and use clinical review where acceptance needs medical judgment.

Security and privacy

Data minimization. Send only the patient information and context the approved workflow needs. Keep credentials and internal routing instructions out of prompt context. Limit telemetry to the identifiers and event metadata needed to investigate an issue.

Retention and deletion. Consultation documents can contain sensitive clinical information. Document which system stores each copy, how long it's kept, who can access it, and how you handle a correction or deletion request under your governing agreement. Send Doctronic-side requests to your implementation contact.

Logging and support. Keep X-Request-ID with each request record, and restrict access to logs that contain user, chat, appointment, or artifact IDs. Report problems as described in report an API problem, and send patient information only through a channel approved for your integration.

Review. Security, permitted data, retention, and incident procedures come from your governing agreement, not from the consumer privacy notice or these docs. Confirm them with your implementation contact. For a security review or supporting documentation without a contact, email business@doctronic.ai, leaving out credentials and patient information.

Production checklist

Access and identity

• The API token and webhook secret live in a server-side secret manager, readable only by the services and operators that need them. See keep the token on your backend.
• Production credentials and user-ID mappings are separate from staging, and you can rotate credentials without a client release.
• Your backend authenticates the patient before selecting X-Doctronic-User-ID.

Conversations and safety

• The stream parser passes the staging tests and ignores unknown event names.
• Completion comes only from ai_consultation.complete; see end states.
• An interrupted turn is reconciled against the transcript and never replayed automatically.
• guardian events follow the behavior in guardian events, with safe fallbacks for unknown guardianId and CTA values.
• Workflow decisions come from events, never from parsing free-form text.

Consultation documents and appointments

• Each artifact ID is stored with its chat and user, 202 is polled with a bound, and 404 and 500 stop retries. See consultation documents.
• Booking collects demographics and a complete address first, and waiting-room URLs are treated as expiring values.

Errors and webhooks

• Mutations send idempotency keys and retries follow the retry checklist.
• Patients see a fallback during prolonged service or network failure.
• Webhook deliveries are verified, deduplicated by eventId, and acknowledged promptly. See webhooks.

Operations

• Dashboards and alerts cover API, stream, webhook, and local workflow failures by endpoint, status, and error code.
• Requests and responses validate against the OpenAPI contract, and you review contract changes before updating clients.
• If you use an SDK, you pin its exact version and read its changelog before each upgrade. See versioning.
• Approved Doctronic attribution and patient-facing copy are in place.
• Doctronic and your on-call contacts and escalation channels are recorded.

Controlled rollout

1. Define the workflow. Document the patient population and entry point, the operations and configured capabilities you use, your identity source and user mapping, the context you pass, safety and error behavior, where consultation documents and appointments go, and who owns support and operations.
2. Request production access. Share your staging evidence, expected traffic, supported workflows, escalation behavior, and operational contacts with Doctronic. Point production traffic at the production base URL from authentication. The SDKs target staging unless you set environment: 'production' in TypeScript, environment="production" in Python, or DOCTRONIC_ENVIRONMENT=production, with the production token.
3. Start bounded. Begin with a population or traffic allocation agreed with Doctronic, and keep a pause or rollback action that leaves patient state intact.
4. Increase deliberately. Review clinical, integration, and operational evidence before each increase. When an acceptance condition fails, reduce or stop traffic, then reconcile incomplete chats, appointments, webhook events, and documents before resuming.

Coordinate material scope changes with Doctronic before you enable them.

Limits

• Production approval, enablement, and rollout are coordinated with Doctronic. There is no self-service approval flow or rollout dashboard.
• The API has no deletion operations for users, chats, messages, or artifacts, and defines no single retention period.
• Public documentation doesn't publish internal prompts, private datasets, or security-sensitive thresholds. Doctronic reviews methodology and implementation-specific evidence with you directly.