Issue: Try It Now runners (TypeScript / Python / Curl) failing in my setup

[fabroos]

Hi! I'm having multiple issues with the Try It Now runners (TypeScript, Python, and Curl). All three runners fail differently, so I'll summarize my setup and the symptoms.

Setup

I'm using @speakeasy-api/docs-md with the following configuration:

/** @type {import("@speakeasy-api/docs-md").Settings} */
export default {
  spec: OPENAPI_YAML,
  output: {
    pageOutDir: './src/app/(api)/api',
    framework,
    aboutPage: false,
    generateRequestBodyExamples: true,
    generateResponseExamples: true,
  },
  display: {
    visibleResponses: 'success',
    expandTopLevelPropertiesOnPageLoad: false,
  },
  codeSamples: [
    {
      language: 'typescript',
      sdkFolder: './sdks/client-ts-1.10.0',
      tryItNow: {
        outDir: './public/try-it-now',
        urlPrefix: '/try-it-now',
      },
    },
    {
      language: 'python',
      sdkFolder: './sdks/client-python-1.9.11',
      tryItNow: {
        outDir: './public/try-it-now',
        urlPrefix: '/try-it-now',
      },
    },
    {
      language: 'curl',
      tryItNow: true,
    },
  ],
};

Problems

1. TypeScript Runner Stuck at “typescript:compiling”

The TS runner never progresses and stays forever in:

{
  "type": "typescript",
  "status": {
    "state": "typescript:compiling",
    "previousEvents": []
  }
}

No console errors are shown.
It feels like the bundler or sandbox isn't finishing compilation.

2. Python Runner — 401 Error + Unsafe Headers blocked in Pyodide

The Python runner crashes with:

{
  "type": "python",
  "status": {
    "state": "python:executing",
    "events": [
      {
        "type": "python:execution:uncaught-exception",
        "error": {
          "message": "API error occurred... Bearer token not found"
        }
      }
    ]
  }
}

Browser console logs:

Refused to set unsafe header "host"
Refused to set unsafe header "accept-encoding"
Refused to set unsafe header "connection"
Refused to set unsafe header "content-length"

It looks like the Python SDK makes an HTTP request where Pyodide tries to set disallowed headers, causing the auth header never to be sent → resulting in a 401.

3. Curl Runner — API returns 422 due to serialized body

The generated curl command:

curl https://api.mistral.ai/v1/chat/completions \
  -X POST \
  -H 'Authorization: Bearer YOUR_APIKEY_HERE' \
  -d '{
    "messages": [
      {
        "content": "ipsum eiusmod",
        "role": "user"
      }
    ],
    "model": "mistral-medium-latest"
  }'

This returns:

{
  "type": "curl",
  "status": {
    "state": "curl:error",
    "events": [
      {
        "type": "curl:fetch:error",
        "error": {
          "message": "API error occurred: Status 422 ... Input should be a valid dictionary"
        }
      }
    ]
  }
}

If I POST with -H "Content-Type: application/json" everything works, so it seems the Try It Now curl content or runner isn't setting a default Content-Type

Summary

TS runner never finishes compiling

Python runner fails because Pyodide blocks unsafe headers

Curl runner appears to be missing Content-Type: application/json or may be encoding payload incorrectly

If you need a minimal repro or a zip of the generated /public/try-it-now folder, I can provide it.

[nebrius]

I'm pretty busy the next couple days, but I'll try and take a proper look soon. Do you have any deadlines for getting this working?

For the TypeScript and cURL cases, do you see this behavior on all endpoints, or just some?

[fabroos]

Will confirm if there's a deadline soon.

---

The Curl i am pretty sure is because of the content-type Header, every single endpoint returns the 422 code

And the typescript is the same behaviour on every single endpoint too

[nebrius]

cURL

I have cURL working by adding the content type header, and just published v0.2.37 with the fix.

TypeScript

For TypeScript, I can't reproduce your error. When I set my config to:

{
  language: 'typescript',
  sdkTarballPath: './sdks/client-ts-1.10.0.tar.gz',
  tryItNow: {
    outDir: './public/try-it-now',
    urlPrefix: '/try-it-now',
  },
},

I get the below output. Now I do see some responsive issues thought that don't appear in base Docs MD examples/test cases, and indicates something with the parent layout in Mistral. I had to force it into single column mode and back out to get the editor to show up. Once I did though, it worked fine:

Screen.Recording.2025-12-14.at.09.57.39.mov

I notice that your config points to an sdkFolder instead of a tarball, but I don't see this folder in https://github.com/mistralai/platform-docs. Here's my diff on the config from main:

diff --git a/speakeasy.config.mjs b/speakeasy.config.mjs
index 571a8f52..f67a1838 100644
--- a/speakeasy.config.mjs
+++ b/speakeasy.config.mjs
@@ -84,13 +84,22 @@ export default {
     {
       language: 'typescript',
       sdkTarballPath: './sdks/client-ts-1.10.0.tar.gz',
+      tryItNow: {
+        outDir: './public/try-it-now',
+        urlPrefix: '/try-it-now',
+      },
     },
     {
       language: 'python',
       sdkTarballPath: './sdks/client-python-1.9.11.tar.gz',
+      tryItNow: {
+        outDir: './public/try-it-now',
+        urlPrefix: '/try-it-now',
+      },
     },
     {
       language: 'curl',
+      tryItNow: true,
     },
   ],
 };

Can you try using my config straight off of main without any other modifications, and see if it works for you?

Python

Unfortunately there's nothing I can do about the header issues from the docs-md side. The issue is that the Python client ends up using httpx under the hood at:

https://github.com/mistralai/client-python/blob/824187dce44c39214a21f51c6ffdd0b78f4b9215/src/mistralai/sdk.py#L95

This line of code is ultimately what's responsible for setting these forbidden-in-the-browser headers. Based on some quick research, it seems like the solution is for Speakeasy to update code samples generation to include a custom client that is browser safe, something like:

from mistralai import Mistral
from ??? import pyodide_compatible_client

with Mistral(
    api_key=...,
    client=pyodide_compatible_client,
) as mistral:

This custom client would somehow need to be made available as part of the Mistral SDK itself so that it's available. @simplesagar what do you think?

[simplesagar]

@fabroos Let me know if the guidance for curl and typescript work for you.

For the python support i'll open a new issue. it looks like a feature request for speakeasy sdk generation to support a new python client.

[fabroos]

I fixed the typescript, it was a mismatch with the versions of esbuild that is installed and the one that the package was refering! Let me know any progress on the python support! Would be ideal to launch first days of next week.