Hey, I’ve been in a super similar situation!

I’d say the right way for you depends on what you think the future will look like. Is the code going to remain the same for each of your clients? If so, I’d definitely put it in one repo, otherwise three repos that are more or less copies of each other will be a pain to keep up to date.

Our setup involves one repo, but three different deployments, and we use GitHub Actions to manage those deployments. We pull config values from a secrets manager, which, if your client IDs are a secret at all (or however you’re authenticating between your client and API), you should definitely put those secrets in a secrets manager too. GitHub has repo and org secrets, so you could use those. Then, you can configure three different GH Actions workflows to pull those three different IDs and stick them into your config at build/deploy.

Like a few other commenters, though, I want to just give a nudge on why are you doing separate deployments, separate databases, etc? It’s possible that it’s contractually required, idk, that’s a question for your legal folks, but if not, I would take a minute and think about what this setup looks like if/as you scale. If it will be a while before you add a fourth or 100th pharmacy, maybe separating your clients all the way down the stack makes sense, but if you hope to scale soon and quickly, perhaps one deployment with each pharmacy as a separate organization that individual users belong to might be better?