Production readiness

Review authentication, streaming, safety, retries, and operations before launch.

Use this review after completing an end-to-end staging integration. Production access and credentials are provisioned manually by Doctronic.

Access and identity

Store the organization Bearer token in a server-side secret manager.
Keep staging and production credentials and user-ID mappings separate.
Verify the local patient identity before selecting X-Doctronic-User-ID.
Restrict which backend services and operators can read or use the token.
Coordinate token delivery, rotation, and revocation with your Doctronic business or implementation contact.
Confirm the production base URL is https://partners.doctronic.ai/api/v1.

Conversation streaming

Parse SSE across arbitrary network chunk boundaries.
Build assistant messages from message.start, message.content, and message.stop.
Key message assembly by messageId.
Ignore unknown event names so additive contract changes remain compatible.
Treat the HTTP connection ending as transport completion only.
Reconcile the transcript before replaying an interrupted turn.
Do not automatically replay an interrupted chat turn. The stream operation does not accept an idempotency key.

Safety and workflow events

If guardian is emitted, route it through the safety behavior approved for your integration.
Map supported skill_code.cta values to explicit product actions.
Provide safe fallbacks for unknown guardian IDs, CTA values, and event names.
Treat conversation.end and ai_consultation.complete as separate signals.
Keep clinical workflow decisions out of free-form text parsing.
Exercise these paths in staging before production access.

Artifacts

Store artifact IDs from ai_consultation.complete with their chat and user scope.
Handle 202 with bounded polling.
Stop retrying on 404 and permanent 500 responses.
Verify the returned chatId before attaching content to a local record.
Render Markdown according to your product's content-safety rules.

Appointments

Collect required demographics and a complete address before booking.
Refresh availability after 409 error.appointments.slot_unavailable.
Retrieve an existing appointment before retrying when a waiting-room error supplies an appointmentId.
Treat a waiting-room URL as a rotating, expiring value rather than a permanent identifier.
Send a unique Idempotency-Key for booking, cancellation, and rescheduling.
Preserve the same request body and key across retries of one intended change.

Errors and recovery

Correct 400 and 422 requests instead of retrying unchanged.
Stop on 401 or 403 and verify credentials and identity scope.
Respect retryAfterSeconds in stream errors when present.
Apply bounded exponential backoff and jitter only to errors documented as temporary.
Retain the X-Request-ID response header with local request metadata.
Define a user-visible fallback for prolonged service or network failure.
Monitor failures by endpoint, status, and machine-readable error code.

Webhooks

Verify X-Doctronic-Signature against the exact raw body before parsing JSON.
Deduplicate processing with the stable eventId.
Return a 2xx response promptly and process work asynchronously.
Ignore unknown event names without returning an error.
Monitor permanent delivery failures and out-of-order events.
Coordinate endpoint, subscriptions, and secret rotation with Doctronic.

Data and observability

Keep Bearer tokens out of source control, client code, logs, traces, and analytics.
Minimize patient content in operational telemetry.
Restrict access to logs that contain user IDs, chat IDs, appointment IDs, or artifact IDs.
Record enough event metadata to investigate stream ordering and integration failures.
Confirm permitted production and staging data practices with Doctronic before launch.

Contract management

Validate requests and responses against the published OpenAPI 3.1 contract.
Review the contract when updating generated clients or validators.
Do not branch on undocumented fields or internal naming.
Verify your consumer continues when it receives an unknown SSE event.

Evaluation and rollout

Record the intended population, workflow, and out-of-scope behavior.
Complete the clinical, safety, contract, and integration-specific evaluation set agreed with Doctronic.
Confirm approved Doctronic attribution and patient-facing copy.
Start with bounded production traffic and a documented pause or rollback action.
Record Doctronic and integration-owner operational contacts.

Share the completed staging evidence, expected traffic pattern, supported workflows, escalation behavior, and operational contact with your Doctronic business or implementation contact. Production enablement is coordinated directly with Doctronic rather than through a public self-service flow.