Daniel DeGroff

> It's very clear you guys are Java developers. Ha.. yes. This is true. I think we do want to be as idiomatic as we can be in each client...

Great, thanks @TruDan - really appreciate the feedback and suggestions.

Thanks @EPRenaud re: the second component -yes, this is something we should fix for sure. Handling via : https://github.com/FusionAuth/fusionauth-netcore-client/pull/27

Thanks for that great detail @TruDan - I merged #27. > So it is possible that settings the developer overrides on DefaultSettings will break json serialisation in fusionauth. This is...

We don't ship any API keys - to use this test, you'll need to add that API key to FusionAuth, or modify the test locally to the API key you...

There are some complications with using our typed objects for `PATCH`. We hope to support JSON Patch (RFC 6902) in the future to help in this area. See https://github.com/FusionAuth/fusionauth-issues/issues/441. If...

I think we have some helper code for this already. https://github.com/FusionAuth/fusionauth-client-builder/blob/f6b91bf5e8bda7921a891a7f25ec98fd02dd0fd6/src/main/client/_macros.ftl#L200 Perhaps we just need to use this macro in more places for python code?

My guess is that the `True` is not serializing to the lower case `true` when converted to a request parameter. Here is where we build the request parameter: https://github.com/FusionAuth/fusionauth-client-builder/blob/d64a871ba9d8fcedc7922bddced491ec80b5bd02/src/main/client/python.client.ftl#L76 And...

Seems to be a bug.

Internal: We can review our current email validation rules in context of various standards for valid characters in email addresses to see if we can further restrict what is allowed....