Currently using Mapbox in an open-source project for their static map API and I wholeheartedly recommend against it. Everything but the simplest of polylines look jagged since they refuse to switch to POST requests with a json body and instead rely on you fitting in as much detail into URL query parameter length constraints.
Going to take a look at replacing them with PMTiles and my own polyline rendering.
I've switched over a fairly large transit client to PMTiles hosted on CloudFlare for their dynamic map and am switching another large transit client to using https://github.com/maptiler/tileserver-gl with MBTiles and the same style.json to generate static maps. It's all gone swimmingly and we've cut costs by about $1,000 a month.
There's actually a reason why most of these APIs support POST—most use-cases are hot-linking, where you don't control how the client makes the request. (Often using an <img>.)
Here's one alternative, if you don't want to build from scratch: https://docs.stadiamaps.com/static-maps/ We don't have much in the way of query string limits, so have at it!
You always have the option of creating a map style and using Mapbox's Raster Tile API - although that does mean you probably can't dynamically adjust your raster images in time for a request to be served.
How are you using the Static Maps API currently where you would be able to send a POST request and display the image back to the user? Most use-cases for the Static Maps API involve the HTML <img> tag or something similar, which all send GET requests.
Rather curious about the URL query parameter length constraint. Excluding IE11/Edge, don't most major browsers have at least 64k query lengths these days? Could you just serve the low quality jaggy poly to few percent still on IE11/Edge and a high detail one to the rest?
Going to take a look at replacing them with PMTiles and my own polyline rendering.