{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidjvi7tcdqjekpzwb4edrrdq4cn7qd54x2plnpxv5hsvpipfdt6ny",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mg2iebx23nz2"
  },
  "path": "/t/responses-api-now-has-expanded-file-input-types-docx-pptx-csv-xlsx/1375013#post_4",
  "publishedAt": "2026-03-02T04:42:45.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "Input_file unreliable on inlined (data:) content (post 2026-02 update) - API / Bugs - OpenAI Developer Community",
    "File inputs | OpenAI API"
  ],
  "textContent": "Thank you for this update! Is it possible to have a bit more details on how the attachments ends up being “attached” to the user prompt?\n\nIn my tests, they seem to be simply appended to the user text, without filename (see Input_file unreliable on inlined (data:) content (post 2026-02 update) - API / Bugs - OpenAI Developer Community).\nWhile `filename` appears to be used in file type detection, the metadata does not appear to be provided to the prompt, and the llm does not seem to be aware it is dealing with an attachment. Any additional details would help us understand pitfalls to avoid (ex. if text files are simply appended, they pose a different prompt injection threat than if they are handled as first class file attachments)\n\nAlso, the documentation at File inputs | OpenAI API should probably be a bit more precise for Base64 - where it says:\n\n\n                    \"content\": [\n                        {\n                            \"type\": \"input_file\",\n                            \"filename\": \"draconomicon.pdf\",\n                            \"file_data\": \"...base64 encoded PDF bytes here...\"\n                        },\n\n\nthe `\"file_data\": \"...base64 encoded PDF bytes here...\"` should probably clarify that the format is actually `data:application/pdf;base64,base64 encoded PDF bytes here`",
  "title": "Responses API now has expanded file input types: docx, pptx, csv, xlsx"
}