Skip to main content

Summarize a customer’s uploaded report

Section: DOC-MA-conversations-attachments#attach-a-stored-file-to-a-conversation.

Build a report-summary flow in which the customer uploads a file, asks for a summary and sees either a completed answer or a clear file/generation failure. Require the report for this recipe so a missing file cannot silently become an answer based only on the prompt.

Before starting, create the customer's thread, configure user-scoped authentication and select a model/provider supporting the file type. You need permission to store the file and disclose its content to that provider. A file ID identifies a stored file; it does not grant access to another user's data.

Step 1: Upload the report and keep its registered ID​

Section: DOC-MA-conversations-attachments#upload-and-register-first.

Follow the file upload guide: request an upload URL, upload with the returned headers, then register the file. Keep the returned fileId. Issuing an upload URL alone does not make a file available to the conversation.

Keep the returned file ID with this upload in your application. If upload or registration fails, resolve that step before offering “summarize”; do not present an issued upload URL as a completed attachment.

Step 2: Require the report for this answer​

Section: DOC-MA-conversations-attachments#decide-whether-the-file-is-required.

Use the fail-generation mode already included in the request below. An answer to “summarize the attached report” would be misleading without the report. Choose content skipping only for another workflow where the omitted attachment is truly optional.

A successful URL resolution does not prove that the provider fetched or understood the file. Check run status, provider errors and the returned answer. MIME metadata is not content validation, and model citations are not proof of correct interpretation.

Step 3: Ask for the summary in the same conversation​

Section: DOC-MA-conversations-attachments#send-the-file-reference.

Use this body with send-message, authenticated for the user entitled to read the file:

{
  "conversationKey": "<your-thread-id>",
  "userMessage": {
    "role": "ROLE_USER",
    "content": [
      {"type": "CONTENT_PART_TYPE_TEXT", "content": "Summarize the attached report."},
      {"type": "CONTENT_PART_TYPE_FILE_ID", "content": "<registered-file-id>"}
    ]
  },
  "overrideGenerationConfig": {
    "fileResolution": {
      "failureMode": "FILE_RESOLUTION_FAILURE_MODE_FAIL_GENERATION"
    }
  }
}

Request example: Send a message to a conversation · Request fields.

The platform resolves the file to a signed provider-fetchable URL. Treat signed URLs as credentials and avoid copying them into chat text, logs or shared links. A URL can expire while a provider is fetching it; a stable ID does not promise that the underlying file exists forever.

Retain the returned run ID and follow generation outcomes. Read the answer only for that run. Finished result: the customer receives the report summary with its actual completion status, or sees why the report could not be used. Review content accuracy; successful URL resolution is not proof that the provider understood the file.

Recover the upload or the accepted summary request​

Section: DOC-MA-conversations-attachments#recover-from-failures.

For a missing file, verify registration and the selected user/project. For unsupported content, select a supported provider or transform the file through a separately authorized flow. Reconcile an accepted run before sending the original message again. See generation outcomes and storage management.

If the response is lost after send acceptance, keep the existing file and run references while reconciling. Uploading another copy or sending the question again is not a status lookup. If later questions need a file that expired, use the supported storage flow to make an authorized file available before a new request.

Document ID: DOC-MA-conversations-attachments. Section identities and revisions.