Go and pay someone who actually knows how to write documentation, and rewrite your client API because method names like

UpdateVerificationFlowWithLinkMethodAsUpdateVerificationFlowBody

is just insane

this stuff is all auto-generated by OpenAPI codegen. It’s funny/frustrating because in Typescript/Javascript you never see this because it’s just used for the types and you just use regular old javascript objects for your payload. In more strictly typed languages (Flutter for us) it’s incredibly verbose. Personal preference but I don’t really like OneOf or Built Value in Flutter. It’s mostly caused by using

OneOf

in the API Spec. This gives you stronger typing in the API client but makes it really verbose. The only real way around it with OpenAPI Spec is to do things like just having “UpdateVerificationFlowBody” with the properties of all the different methods, and checking at call time whether you’ve set the right properties

Thanks @dazzling-napkin-4938 that is literally the problem. Unfortunately the OpenAPI code generation templates for less used languages is pretty poor. It works well with TypeScript and I think Java but all other clients are kinda meh. Unfortunately there are no better code generation tools on the market (even paid ones). We essentially need one team per SDK language which is currently not possible. We do have ideas to move everything to gRPC at some point but it’s also not clear if it really improves the API significantly or just shifts the problems elsewhere.

I agree with all those points re. openapi codegen - we use it for building SDKs for our API and it’s a similar story. The other thing fairly specific to Ory that makes things tricker is that Ory (Kratos at least anyway) makes fairly heavy use of http errors as part of the main workflow. eg - updating a login flow with an incorrect password - Kratos will return an updated flow but as a 400 error with the flow in the response. This is correct as a workflow, but isn’t that pleasant to work with in the SDK. In most of the SDKs the error response payload is completely untyped, and so you end up needing to inspect the error and deserialise it yourself. But yeah this is just OpenAPI, and I think you’re right the only real solution is to have human-written SDKs for each language you want to support, which has its own problems

If you are thinking about moving to a different API framework, https://connectrpc.com/ might be more interesting than gRPC. It will be easier to consume from browser apps and manual playing around