We've refreshed the medical databases that power the symptom checker interview in the sandbox environment. This refresh brings the medical content in the sandbox environment closer to the medical content that is found in our production environment. This means that you will see more similar question logic, complaint interpretations, and images (to name a few) between the sandbox and production environments.

Previously, calling the read complaint endpoint when there was an outstanding question to be answered would return a link to the complaint itself as seen in the example below.

We're excited to announce the release of our v2.0 Buoy Symptom Checker API into our sandbox environment. To begin the transition, organizations should review our v2.0 migration guide.

We're getting close to the release of the v2.0 Buoy Symptom Checker API! We're excited to release our updated documentation and API reference ahead of our sandbox release. More on that below.

Beginning in July, the Buoy API team will be introducing a new version of the Buoy symptom checker API. The upcoming version of our API lays the framework for us to implement new developer tools. Additionally, we will be simplifying some of our API request and response bodies.

We know that high-quality documentation is essential for any API. As we move forward and expand Buoy's API, our goal is to always provide users with helpful, thorough, up-to-date documentation. That's why we're so excited to announce the launch of our new and improved docs today!

• Removed potentially misleading triage object from triage_explanation → potential_condition in results
  • Endpoint: results_read (GET /results/{{token}}/)
  • Response body schema change: Removed the triage attribute found at triage_explanation.potential_condition.triage
  • Rationale: The removed triage object created confusion when compared the top level triage object. For clarity and simplicity, we are removing triage_explanation.potential_condition.triage. If needed, please use the top level triage object.
• Question options payload has been updated
  • Endpoints:
    • questions_list (GET /questions/)
    • questions_read (GET /questions/{{token}})
  • Response body schema change: added free_text attribute to objects in options[]
  • Rationale: for options where free_text is true (e.g. “Something else”), the client can choose to populate the extra attribute in the question answer
• Alt text now available on questions and options
  • Endpoints:
    • questions_list (GET /questions/)
    • questions_read (GET /questions/{{token}}/)
  • Response body schema change: added media_alttext attribute to the top level of the response body and to objects in options[]
  • Rationale: alt text enables clients to implement more accessible experiences

• Updated user profile age range, only profiles with an age range of 2 to 120 years old are accepted.

• Updated interview endpoint to allow the creation of an interview without 'location' or with 'location': null.
• Updated error code from 400, Bad Request, to 422, Unprocessable Entity, if our system cannot approximate a location based on the IP address of the request.

• Dropped the deprecated interview_mode flag.
• Dropped support for legacy mode names (i.e., 'safe' and 'triage').
• Generalized 'complaint' mode name to 'input' to make room for diagnoses of concern; this update should not pose problems since 'complaint' mode was the default mode to start an interview and transitions to the mode have always returned 202.
• Updated the response body for all interview update calls to include the interview representation; nested the developer-facing 'msg' key in '_links'.
• Updated the NOP response for requests to manually set interview mode to 'input' so that the message is returned by key-value pair.
• Deprecating 202 status codes, in favor of 200 status codes, for interview mode update requests that do not produce questions or results; the 200 response better reflects that the mode update is committed to the database whether a new question/result is available or not.