Developers

Test your integration

Validate identity scoping, event handling, artifacts, and care workflows before production.

Use the staging environment to exercise the full workflow before requesting production access. Staging credentials are provisioned manually by Doctronic and are separate from production credentials.

export DOCTRONIC_API_URL="https://staging-partners.doctronic.ai/api/v1"
export DOCTRONIC_API_TOKEN="replace-with-your-staging-token"

Ask your Doctronic business or implementation contact what test data is permitted in your staging integration. Do not assume production records or credentials work in staging.

Validate the primary path

Run at least one complete test that:

  1. Creates a user and stores data.id.
  2. Creates a chat for that user.
  3. Streams several patient turns.
  4. Reassembles assistant content by messageId.
  5. Handles all recognized control events separately from content.
  6. Detects consultation completion only from ai_consultation.complete.
  7. Retrieves each returned artifact ID, including a temporary 202 response.
  8. Lists the chat messages and verifies the displayed transcript can be restored.

The transcript endpoint returns the visible user and assistant transcript. Consultation artifacts use their own retrieval endpoint and should be tested independently.

Exercise identity boundaries

Confirm your backend always sends the correct credentials for the current user.

TestExpected result
Missing or invalid Bearer token401 error.auth.unauthorized
User ID outside the authenticated organizationAccess is denied or the resource is masked as unavailable according to the endpoint contract.
Chat ID belonging to another user404 error.partner.chat_not_found
Artifact ID outside the current organization or user404 error.artifact.not_found

Do not log the credential values during these tests.

Stress the stream parser

SSE frames can be split across network chunks. Test a parser that:

  • Buffers partial lines and partial JSON payloads.
  • Supports multiple frames in one network chunk.
  • Preserves frame order within one HTTP response.
  • Associates content with its messageId.
  • Ignores unknown event names.
  • Handles a connection ending before a complete frame.
  • Treats an error event differently from an HTTP error response.
  • Respects retryAfterSeconds when it is present.

Do not use the browser's native EventSource interface for this endpoint because the stream is a POST. Use fetch() or consume the stream on your backend.

Validate negative inputs

Include cases for:

  • An invalid IANA timezone, which returns 400 for 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 does not match the OpenAPI schema.
  • An unrecognized event type, which your consumer should ignore.

Exercise care workflows

If your integration offers appointments, test:

  • Missing required user demographics.
  • Missing or incomplete address fields.
  • A chat that is not ready for appointment booking.
  • No available practitioners in the requested state.
  • A scheduled slot becoming unavailable, which returns 409.
  • An ASAP booking whose waiting-room URL is temporarily unavailable.
  • Retrieval before retry when the error contains an existing appointmentId.
  • Cancellation and rescheduling from the latest appointment state.

Verify booking, cancellation, and rescheduling with a unique Idempotency-Key. Repeat the same request with the same key and confirm Idempotency-Replayed: true, then confirm that changing the payload while reusing the key returns 409.

Define release evidence

Before production access, retain evidence that your integration can:

  • If a guardian event is emitted, route it through the safety behavior approved for your integration.
  • Restore a transcript after reconnecting.
  • Distinguish stream completion from consultation completion.
  • Handle artifact 202, 404, and 500 responses.
  • Apply the documented idempotency behavior and bound retries for temporary failures.
  • Retain X-Request-ID for failed requests.
  • Verify signed webhook delivery and duplicate eventId handling if webhooks are enabled.
  • Keep tokens and user-scoped identifiers out of client code and unrestricted logs.
  • Continue safely when a new SSE event name appears.

Use Production readiness for the final review and coordinate production credentials with your Doctronic business or implementation contact.

On this page