Update application/json to multipart/form-data

[Agbaje Olalekan (olalekan-agbaje)]

User description

Change content type from application/json to multipart/form-data to match api expectations

---

PR Type

Documentation

---

Description

• Switch replay callback request body content type

• application/json replaced by multipart/form-data

• Aligns OpenAPI spec with actual API behavior

---

Diagram Walkthrough

flowchart LR
  A["ReplayCallbackRequest body"] -- "content type update" --> B["multipart/form-data"]

Loading

File Walkthrough

	Relevant files
Documentation	v3-replay-callback.yaml Update replay callback request media type                                specs/v3/v3-replay-callback.yaml Changed requestBody content media type from application/json to multipart/form-data Schema reference ReplayCallbackRequest and example remain unchanged +1/-1

---

---

Need help?

Type /help how to ... in the comments thread for any questions about PR-Agent usage.

Check out the documentation for more information.

[prfectionist]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪

🏅 Score: 80

🧪 No relevant tests

🔒 No security concerns identified

🔀 No multiple PR themes

⚡ Recommended focus areas for review Spec Consistency The request body content type was changed to multipart/form-data only for this endpoint. If other endpoints in the v3 specs (or the SDK/client code generated from these specs) still declare application/json for similar callback/replay bodies, the specs become inconsistent and generated clients may send the wrong content type. Also worth confirming the API truly rejects application/json here; if it accepts both, listing both content types would be more accurate than replacing one with the other. multipart/form-data: schema: $ref: '#/components/schemas/ReplayCallbackRequest'

[prfectionist]

Suggestion: Switching this simple structured body to multipart/form-data breaks existing JSON clients and loses type fidelity (multipart parts are transmitted as strings, so schema validation/coercion of callback_url becomes ambiguous). Since no binary/file upload is involved, keep application/json — or at minimum declare both media types so current integrations continue to work. [possible issue, importance: 6]

New proposed code:

 content:
+  application/json:
+    schema:
+      $ref: '#/components/schemas/ReplayCallbackRequest'
+    example:
+      callback_url: 'https://partner.example.com/webhook'
   multipart/form-data:
     schema:
       $ref: '#/components/schemas/ReplayCallbackRequest'
     example:
       callback_url: 'https://partner.example.com/webhook'

[Ed Fricker (beastawakens)]

Agbaje Olalekan (@olalekan-agbaje) Thanks for the PR but we should fix this in the source repo...