file part not the request header

Not specified by the original author.

TL;DR

Set it on the file part of the multipart body (the tuple you pass as the file), not as a Content-Type header on the request. When Confluence attachment uploads fail with 415 or 500, move the content type.

Steps

1. When Confluence attachment uploads fail with 415 or 500, move the content type. Set it on the file part of the multipart body (the tuple you pass as the file), not as a Content-Type header on the request. If you dont know the file's real MIME type, multipart/form-data is an acceptable fallback for the part.

When to use

You are seeing this: When Confluence attachment uploads fail with 415 or 500, move the content type. Use this skill when you run into "Confluence REST API: put the content type on the file part, not the request header".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow #35286227 (accepted answer, 6 votes): the asker uploaded attachments with Python requests and got 415 unsupported media type or 500 errors depending on how the request was built. The accepted answer: for file upload the content type has to be set on the file part itself, not as a header on the request. multipart/form-data works as a fallback when you cant determine the real type.

Verified resolution: When Confluence attachment uploads fail with 415 or 500, move the content type. Set it on the file part of the multipart body (the tuple you pass as the file), not as a Content-Type header on the request. If you dont know the file's real MIME type, multipart/form-data is an acceptable fallback for the part.

Source URL: https://stackoverflow.com/questions/35286227/uploading-attachments-to-confluence-rest-api-with-python-requests-gives-415-and-500-erro

Not specified by the original author.

TL;DR

For "`` *** square.core.api\error.ApiError: status\code: 400, body: {'errors': [{'category': 'INVALID\REQUEST\ERROR', 'code': 'INVALID\CONTE": the SDK's File type lets you set it explicitly: pass a tuple like (os.path.basename(pdf\filepath), open(pdf\filepath, 'rb'), 'application/pdf') as imagefile in create\invoice\attachment so the multipart part carries the right content type.

``` *** square.core.api_error.ApiError: status_code: 400, body: {'errors': [{'category': 'INVALID_REQUEST_ERROR', 'code': 'INVALID_CONTENT_TYPE', 'detail': 'Received multiple request parts. Please only supply zero or one `parts` of type application/json.' }] } ```

Steps

1. The 'Received multiple request parts' error on invoice attachments means the server cannot parse the file's Content-Type. The SDK's File type lets you set it explicitly: pass a tuple like (os.path.basename(pdf_filepath), open(pdf_filepath, 'rb'), 'application/pdf') as imagefile in `createinvoice_attachment` so the multipart part carries the right content type.

When to use

You are seeing this: The 'Received multiple request parts' error on invoice attachments means the server cannot parse the file's Content-Type. Use this skill when you run into "Square API for invoice attachments 'Received multiple request parts. Please only supply zero or one parts of type appl".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/square/square-python-sdk/issues/150:

Issue gh:square/square-python-sdk#150: the reporter asked: Issue square/square-python-sdk#150 (closed, 6 comments): Describe the bug I am continually getting the multiple request error when invoking invoices.createinvoiceattachment `` *** square.core.api_error.ApiError: status_code: 400, body: {'errors': [{'category': 'INVALID_REQUEST_ERROR', 'code': 'INVALID_CONTENT_TYPE', 'detail': 'Received multiple request parts. Please only supply zero or one parts of type application/json.' }] } **Expected behavior** The API should attach a file in dev to an invoice and return a successful attachment JSON **To Reproduce** 1. setup python app to use square package using pip 2. invoke create_invoice_attachm The verified answer was: The 'Received multiple request parts' error on invoice attachments means the server cannot parse the file's Content-Type. The SDK's File type lets you set it explicitly: pass a tuple like (os.path.basename(pdffilepath), open(pdffilepath, 'rb'), 'application/pdf') as image_file in createinvoiceattachment` so the multipart part carries the right content type. Evidence thread: https://github.com/square/square-python-sdk/issues/150

Not specified by the original author.

TL;DR

Always send the SearchApi key in the Authorization header instead of the URL. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key. You get the same auth with none of the key-in-logs exposure that the query-param form creates.

Fix

1. Always send the SearchApi key in the Authorization header instead of the URL. Expected: You get the expected result; the problem is gone.

2. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key. Expected: You get the expected result; the problem is gone.

When to use

• You are setting up or using this SearchApi feature.
• The symptom matches: put the api key in the Authorization header, not the query string.

When NOT to use

• Unrelated SearchApi issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against SearchApi.

Variant phrasings

put the api key in the Authorization header, not the query string

Why it happens

Official docs: the SearchApi docs for the TikTok profile videos engine document two ways to pass the api key, as a query parameter on the URL or in the Authorization header as a bearer value. The docs show the query param form in examples, but every URL with the key in it gets written into server logs, search history, and browser history. The gotcha is that the convenient copy-paste example is the leaky one. Docs: https://www.searchapi.io/docs/tiktok-profile-videos-api

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Official docs: the SearchApi docs for the TikTok profile videos engine document two ways to pass the api key, as a query parameter on the URL or in the Authorization header as a bearer value. The docs show the query param form in examples, but every URL with the key in it gets written into server logs, search history, and browser history. The gotcha is that the convenient copy-paste example is the leaky one. Docs: https://www.searchapi.io/docs/tiktok-profile-videos-api Resolved: always send the SearchApi key in the Authorization header instead of the URL. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key. You get the same auth with none of the key-in-logs exposure that the query-param form creates. This matters doubly because SearchApi keeps a search history endpoint: any request you made with the key in the URL sits in your history with the full request URL attached, visible to anyone with account access for 90 days. Source: https://www.searchapi.io/docs/tiktok-profile-videos-api