Skip to content
Summer Docs
DocumentationOpen Summer ↗
Documentation /

Clinician chat and account links

Send patients to the relevant conversation, plan or order.

When a customer asks a clinical question, Summer refers them to a clinician and provides the most relevant available destination. Summer does not answer the clinical question or repeat medication directions.

Public destinations

In Settings → Integrations → Summer Messenger, configure:

  • Clinician chat URL: your authenticated care-message page.
  • Sign-in URL: a login destination that returns patients to care messages.
  • Public care or catalog URL: where a new visitor can learn about your services.
  • Optional offer label and URL: a real membership or care-plan offer you want to make available to new visitors.

A signed-out visitor might already be a customer. Summer can offer sign-in without claiming that they have no account. Without verified identity, it receives no patient-specific links.

Patient-specific destinations

Your identity endpoint can include care_context in the signed assertion. Build it from records owned by the currently verified account. The browser cannot supply or override these destinations independently.

{
  "care_context": {
    "care": [
      {
        "label": "Current treatment",
        "chat_url": "https://portal.example.com/messages/conversation-123",
        "plan_url": "https://portal.example.com/plans/plan-456",
        "order_url": "https://portal.example.com/orders/order-789"
      }
    ]
  }
}

label and chat_url are required for each entry. plan_url, order_url and started_at are optional. Use short treatment or visit labels; do not include clinical messages, medication directions or a full chart.

Summer checks signed destinations against your allowed website origins and Additional destination origins. Add an exact HTTPS origin there when your patient portal is hosted separately. Usernames, passwords and access-token query parameters are refused. Links must open your normal authenticated pages, not bypass login.

The complete signed assertion is limited to 8,192 characters. Send navigation metadata rather than account history; a basic signed identity without care context is valid. Rebody falls back to its configured public care destination if its optional context cannot be read or exceeds the transport size.

The context expires with the short widget session and is replaced at identity renewal. If current context is unavailable, Summer falls back to your public care/sign-in destinations. It does not conclude that the patient has no treatment.

Summer uses the chat matching the treatment or refill in the customer's question. An order question can link to the relevant order; a plan question can link to the relevant plan. If several entries could match, Summer asks which treatment or visit they mean or opens your conversation picker. It does not assume the newest treatment is relevant.

For a visitor, a typical referral is: “That's a question for a clinician on our platform. If you already have an account, sign in to message your care team.” The configured sign-in link follows it.

A link opens the destination. It does not send a clinician message, create an appointment or confirm that a clinician has read anything.

Optional membership invitation

For a new visitor, Summer may add one brief invitation using your configured offer and the current terms in your assistant knowledge. Nothing is offered by default. Do not suggest an additional purchase for a question about existing care, and do not add a sales pitch to an urgent concern.

Rebody's integration

Rebody uses this same signed care-context format. Its backend resolves owned clinician conversations, plans and unambiguous order links using Rebody's portal link builders. The Summer widget and referral API consume the common format; other companies supply their own account IDs and destinations.

UP NEXTAssistant and knowledge →