commerce.media.uploadVideo sends Content-Type: application/json instead of application/octet-stream

[dantio]

Summary

commerce.media.uploadVideo(videoId, body) posts the raw video binary using the default request Content-Type: application/json. eBay's Media API expects the video to be uploaded as a raw binary stream with Content-Type: application/octet-stream, so uploads sent through this method are likely rejected or mishandled by eBay unless the caller manually overrides the header.

Location

src/api/restful/commerce/media/index.ts

async uploadVideo(videoId: string, body?: any) {
  videoId = encodeURIComponent(videoId);
  return this.post(`/video/${videoId}/upload`, body);
}

The shared REST layer applies defaultApiHeaders with Content-Type: application/json (src/api/restful/index.ts), and uploadVideo does not override it.

Details

• The OpenAPI spec (specs/commerce_media_v1_beta_oas3.json) does not declare a requestBody/content type for uploadVideo, so this is not caught by the generated types. The requirement (application/octet-stream for the raw .mp4 stream) comes from eBay's Media API documentation and the method's own description ("the input stream for the video source ... an .mp4 file").
• This is pre-existing behavior (not a regression) — it predates the v10 work. It was surfaced during a bug hunt of the v10 branch.
• Sibling upload methods that require multipart/form-data (createImageFromFile, uploadDocument, uploadPostOrderDocument) were just fixed to use the existing multipartHeader helper. uploadVideo differs because eBay expects application/octet-stream for video, not multipart — hence a separate issue.

Suggested fix

Set the octet-stream content type on the request, e.g.:

async uploadVideo(videoId: string, body?: any) {
  videoId = encodeURIComponent(videoId);
  return this.post(`/video/${videoId}/upload`, body, {
    headers: {
      'Content-Type': 'application/octet-stream'
    }
  });
}

Optionally add a shared octetStreamHeader constant in src/request.ts (mirroring multipartHeader) if more binary-stream uploads are added later.

Verification suggestion

Add an assertion in the OAS test harness (or a targeted unit test) that uploadVideo issues the request with Content-Type: application/octet-stream.

[dantio]

Fixed in v10.0.0 (npm i ebay-api@10.0.0), via #216.

uploadVideo now sends Content-Type: application/octet-stream using a shared octetStreamHeader in src/request.ts, as suggested. It also takes an optional third headers argument so Content-Range / Content-Length can be supplied for resumable uploads.

Investigating this surfaced a second bug one layer down: enrichRequestConfig spread the default headers after the per-request ones, so Content-Type: application/json overwrote any override. That meant the multipart/form-data fix for createImageFromFile, uploadDocument, uploadPostOrderDocument, sell.feed.uploadFile and sell.fulfillment.uploadEvidenceFile had never actually reached the wire either. Header merging is now least- to most-specific (defaults → app config → per-request → signature), covered by regression tests.

Note this is a small breaking change: a per-request Content-Type now wins over one set globally through apiConfig.headers.