We’re seeing random 415 Unsupported Media Type errors on the Guest API file upload endpoint when triggered from a Studio SNIPPET action. The flow is supposed to attach a scanned document to the conversation context before routing to a skill group.
SNIPPET action looks like this:
GetRESTProxy(“POST /api/v2/webmessaging/conversations/{conversationId}/fileUploads”)
ASSIGN fileData = BASE64_DECODE(session.fileContent)
ASSIGN headers[“Content-Type”] = “application/pdf”
The issue is intermittent. Small PDFs under 5MB go through fine. Anything pushing 7MB or a PNG image drops the 415 immediately. Studio logs show the request payload is identical, just the size changes. Checked the MIME type mapping in the SNIPPET, seems solid.
Walked through the SNIPPET logic step by step. First, the session variable fileContent gets populated from the webhook payload. Then we decode the base64 string. The REST Proxy is configured with client_credentials auth, token is fresh. Verified the endpoint path matches the v2 docs.
The weird part is the 415 code. Usually, that means the server doesn’t understand the format. PDFs work. PNGs fail. Even a 1KB PNG fails with 415. Size seems irrelevant for the image types. PDFs over 10MB also fail, but that returns a 413. So we’ve got two distinct failure modes.
We’ve been banging our heads against this for a day. The SNIPPET returns the error code in the result object, so we can see the 415 clearly. Response body is empty though, no helpful error message. Just status 415. The JSON response from the SNIPPET shows “status”: 415 and “body”: “”. We’re parsing the status code to route to an error queue, but the flow execution time spikes to 12 seconds before the timeout.
Thinking the MIME whitelist might be restricted on the backend for programmatic uploads. SDK docs mention application/pdf, image/jpeg, image/png. Studio SNIPPET is sending exactly image/png.
Could be the REST Proxy is mangling the binary data during the header assignment? Tested with a static string payload, works. Binary stream assignment might be the culprit.
Tried adding an IF condition to check the file extension before the ASSIGN, but the webhook doesn’t always pass the extension reliably. Guests can rename files.
Also, the SDK on the web widget has a config for maxFileSize, but that’s client-side. We need to enforce this server-side in Studio to prevent the flow from hanging on a failed upload.
We’re running Studio 4.2.1. Patch level is current. Is there a way to inspect the accepted MIME types via an API call? Maybe hit a metadata endpoint? Or is this purely hardcoded in the platform?
Stuck on the binary stream assignment theory. Need to get this routed before the queue fills up.