Hi @jhildenbiddle,
Unfortunately you can’t, since the idea behind oembed is to display an existing document (sigh). I’m really not a fan of oembed, as a lot of the protocol is fairly constrictive and meant to satisfy pretty static insertions from when it was originally developed (and the unfortunate thing is that “the oembed standard” really just means “what works in Medium” these days).
The query parameters are in theory owned by the oembed spec, although I suppose we could of course namespace them or something (like &runkit:nodeVersion=... or whatever). This seems like a feature that wouldn’t get a ton of use though since 99% of the “oembed workflow” seems to be driven around the idea of someone pasting an existing link in somewhere, and it getting swapped out for the embed and not really giving the “user” a ton of ability to edit the actual oembed request link, and thus requiring the “editor” in question to have custom UI for setting that sort of thing, and thus defeating the point of a “neutral” API.
We could alternatively bake these query parameters into the actual document URL, such that it would be something like https://embed.runkit.com/oembed?url=“https%3A%2F%2Frunkit.com%26nodeVersion%3D18.x.x”, but that would really solely serve the oembed case since those parameters would be ignored normally. So the user would have to know to append parameters that do nothing, just so that when they paste into an oembed compatible UI (Medium), it will change these options.
As you can probably tell I am not a fan of oembed. However, I am willing to try to figure something out. Is oembed an absolute requirement for how you presenting the embeds? Just as an FYI, oembeds have a number of other (either unresolvable or very difficult to resolve) problems that mean a worse experience. For example, you probably aren’t getting the benefit of our single-load infrastructure from just using embeds directly (whether you load one RunKit embed or 100, the memory usage is nearly identical with the main embed API since they all “share” one running code instance, each one doesn’t reload all of RunKit like other iframe services out there do). However, oembed usually means the embeds are trapped in another layer of iframe(s), which makes this much more difficult (for example, on Medium, there’s like 2 extra iframes they put in-between their page and the embed).
As a super quick hack though, you can always just make a document with the desired node version etc, and just use that for the embed. So if all you want is just the welcome document with the updated node version, you can clone it, change the node version, and then just use that for the oembed. Again though, depending on the use case, this may not be all that helpful. Happy to know more to hopefully provide a better answer!