Share via

Databricks Genie API returns preliminary answer, not the final one shown in Genie UI

Abdallah Al-Zu'bi 0 Reputation points
2026-04-06T21:15:40.6333333+00:00

I'm calling the Genie Spaces API (/api/2.0/genie/spaces/{space_id}/) from a custom Flask app. I start a conversation, poll the message until status: COMPLETED, then read the text attachment and query results.

Problem: The API returns an initial/preliminary answer that differs from what the Genie workspace UI eventually displays for the same question.

What I've tried:

  • Re-polling the message for 30+ seconds after COMPLETED — text never changes
  • Checking attachment.query.status and statement_response.status.state — both show completed
  • Comparing full JSON snapshots across multiple polls — identical every time

Questions:

  1. Does Genie internally process multiple rounds/messages that I need to poll separately?
  2. Is there an additional endpoint or message ID for the final refined answer?
  3. Does the Genie UI use a different API flow that re-submits the query?Title: Databricks Genie API returns preliminary answer — not the final one shown in Genie UI
Azure Databricks
Azure Databricks

An Apache Spark-based analytics platform optimized for Azure.

0 comments
Answer accepted by question author
  1. Manoj Kumar Boyini 11,280 Reputation points Microsoft External Staff Moderator
    2026-04-06T22:32:20.9166667+00:00

    Hi Abdallah Al-Zu'bi

    What you are observing is expected behavior based on how the Databricks Genie Conversation API works compared to the Genie UI.

    When you call the Genie API and poll a message until its status becomes COMPLETED, the response you receive in the attachments field is the final result for that specific API execution path. The API does not provide a second “final answer” later, and there is no additional endpoint that returns a refined version after completion.

    The difference you are seeing between the API response and the Genie UI is because the UI can perform additional refinement steps that are not automatically triggered in your API flow. In the Genie UI, features such as Inspect, Fix it / try again, or internal regeneration can re-run or improve the generated SQL and response before displaying it. This can result in a more refined or human-friendly answer compared to the initial completed response returned by the API.

    From the API perspective:

    • A message reaches COMPLETED when Genie has finished generating the response for that request
    • The attachments array contains the response text, generated SQL (if any), and references to query results
    • Query results are retrieved separately using the attachment ID
    • The response will not change after the message is marked COMPLETED

    Because of this, re-polling the same message will always return identical results, which matches what you are observing.

    If you want to replicate the UI behavior more closely, you would need to explicitly implement additional steps such as re-submitting the query, applying feedback, or simulating refinement logic in your application. The API itself does not automatically perform multiple refinement rounds for a single message.

    Helpful References:
    https://docs.databricks.com/aws/en/genie/conversation-api
    https://docs.databricks.com/aws/en/genie

    The API is returning the correct completed response, and the difference you see in the UI is due to additional refinement or regeneration flows that are not part of the single API call lifecycle.

    Hope this helps. Please let us know if you have any questions or concerns. If this solves your issue, kindly click “Accept Answer” so it can help others in the community.

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-04-06T21:15:53.8933333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The Genie Conversation API and the Genie UI use the same underlying conversation model and message flow. The behavior described is not caused by a documented “preliminary vs. final” answer mechanism or a separate hidden endpoint.

    Based on the documented flow:

    1. Start a conversation with:
      • POST /api/2.0/genie/spaces/{space_id}/start-conversation
      • This returns a conversation_id and initial message_id.
    2. Poll the message until completion:
      • GET /api/2.0/genie/spaces/{space_id}/conversations/{conversation_id}/messages/{message_id}
      • When status is COMPLETED, the response is stable and the final content is in the attachments array. The documentation does not describe any further internal refinement step that would change that text later.
    3. Retrieve query results if present:
      • Use attachment_id from the attachments array with:
      • GET /api/2.0/genie/spaces/{space_id}/conversations/{conversation_id}/messages/{message_id}/attachments/{attachment_id}/query-result
    4. Ask follow‑up questions in the same conversation:
      • POST /api/2.0/genie/spaces/{space_id}/conversations/{conversation_id}/messages
      • Each follow‑up creates a new message_id under the same conversation_id.

    Given this documented behavior, the answers to the specific questions are:

    1. Does Genie internally process multiple rounds/messages that need to be polled separately?
      Multiple rounds only occur when additional messages are explicitly posted (for example, follow‑up questions). Each POST creates a new message_id that must be polled independently. There is no documented hidden internal chain of messages for a single user question that must be polled separately.
    2. Is there an additional endpoint or message ID for a final refined answer?
      No additional endpoint is documented beyond the message and attachment query‑result endpoints:
      • GET .../messages/{message_id}
      • GET .../messages/{message_id}/attachments/{attachment_id}/query-result
        When status is COMPLETED, the attachments content is the final answer for that message.
    3. Does the Genie UI use a different API flow that re‑submits the query?
      The documentation describes the Conversation API as the same mechanism used to power natural language querying and multi‑turn conversations. It does not document a separate UI‑only refinement flow or re‑submission path that would produce a different “final” answer than what is returned when status: COMPLETED for a given message.

    If the UI is showing a different answer than the one returned by the Conversation API for the same conversation_id/message_id, this is not covered by the documented behavior and would require product support investigation (for example, checking whether the UI actually created a different conversation or follow‑up message than the one being polled from the custom app).

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.