Have the /v1/orchestrate/upload-to-s3 be OpenAI compatible - API design incompatibility is blocking third-party integration

The current API for uploading files into Orchestrate: /v1/orchestrate/upload-to-s3
https://developer.ibm.com/apis/catalog/watsonorchestrate--custom-assistants/api/API--watsonorchestrate--agent-execution-and-runtime#upload_to_s3_v1_orchestrate_upload_to_s3__post

is not compliant with the file API of OpenAI: https://developers.openai.com/api/reference/resources/files/methods/create

The POST /v1/orchestrate/upload-to-s3 endpoint deviates from the OpenAI Files API standard (POST /v1/files) on three key dimensions. These deviations prevent any OpenAI-compatible integration framework from calling the WxO upload endpoint natively, requiring a custom proxy layer in every integration.

Aligning upload-to-s3 with the OpenAI standard would enable direct, zero-glue integration for any tool or platform that already supports the OpenAI Files API.

Proposed Changes

1 Accept file as field name (Issue 2.1)

Accept file (singular) as an alias for files in the multipart request body, consistent with the OpenAI standard and the behaviour of all OpenAI-compatible client libraries.

2 Return a JSON object for single-file uploads (Issue 2.2)

Return a flat JSON object (not an array) when a single file is uploaded, consistent with the OpenAI standard. For multi-file uploads, return an object with a files array, or a separate response per file.

3 Return a short id field (Issue 2.3 — primary request)

Surface the UUID already present in the presigned URL path as a top-level id field in the response:

{
  "id": "f41884d6-a354-44a9-af4f-364ad2e3c7e6",
  "object": "file",
  "filename": "document.pdf",
  "bytes": 231403,
  "created_at": 1728469010,
  "expires_at": 1728472610,
  "status": "processed",
  "url": "https://s3.us-south.../document.pdf?X-Amz-..."
}

The id field requires no new server-side logic — it is the UUID already generated and embedded in every presigned URL path segment. Exposing it as a dedicated top-level field costs nothing and unlocks native integration for all OpenAI-compatible clients.

4 Optional: file retrieval endpoint

Add a companion endpoint:

GET /v1/orchestrate/files/{file_id}

that returns a fresh presigned URL for a stored file id. This mirrors GET /v1/files/{file_id}/content from the OpenAI standard and would allow clients to store only the short id and regenerate the presigned URL on demand, eliminating expiry concerns entirely.