Because advanced themes are so customizable, they can be hard to upgrade. Here's some ways to make it easier.

When you create a new theme, start from the default version. Commit it to git before you change anything. Use the FusionAuth CLI to download/upload your theme during development and CI/CD. When a new theme comes out, clone or pull the latest from the theme history repo. Run this command to see what has changed: git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch (this shows the changes between 1.61.0 and 1.64.1; adjust as needed for your installed version and the target version). Go to your theme git repo and apply the changes: git am --3way update-themes.patch which will attempt to automatically merge the changes. If there are conflicts, you can resolve them manually and then run git am --continue.

You can also use a 3 way diffing tool like diff3 or kdiff3 to visualize the changes.

These upgrade notes also provide detailed human friendly instructions on the changes.

It's so easy to mix up those IDs when you're moving between FusionAuth and the Google console! It’s definitely one of those things that’s right under your nose but impossible to see until someone points it out. Glad to hear you got the callback working - that 'invalid_client' error can be a real headache when everything else looks correct.

I've found that setting the mobile number as the loginId is the most reliable way to handle this right now. You can just tweak the theme labels to say 'Mobile Number' instead of 'Username' so it's clear to the users. It’s a bit of a manual setup for the SMS verification part via the API, but it gets the job done without waiting for a native feature update.

@mark-robustelli cheers, that was a useful post. The IAMShowcase tools did help me filter out what was correct and what was not. Eventually I found that the compression config settings on the passed request were not correct.

Managing users in bulk can definitely be a bit nerve-wracking when you're doing it for the first time.
If you’re looking for a quick way to handle this, the FusionAuth Search API is probably your best friend here. You can run a query to get the IDs of the users you want to target, and then loop through them with a simple script using the Delete User API.
If you just want to "deactivate" them instead of a hard delete, you can toggle the active flag to false in the User object. This is usually a safer bet if you think you might need to reactivate them later without losing all their historical data or linked identities. Just a heads-up: make sure you have a good backup of your database before running any bulk scripts—it's saved my skin more than once!

Webhook errors can be a real pain to debug since they often fail silently or with very generic messages. I’ve found that most of the time it comes down to either a TLS/SSL handshake issue or the endpoint expecting a specific header that FusionAuth isn't sending.
One thing that really helps is using a tool like Webhook.site or RequestBin just to see if the event is actually firing and what the payload looks like. If it works there but not on your server, it’s almost certainly a firewall or certificate trust issue on your end. Also, double-check that your secret is matching up perfectly - it’s easy for a stray whitespace to throw the whole signature validation off!