How to implement Web API with many databases depending on client calling

I have to create a RESTful Web API (I'm using ASP.NET Core 1.1) for a system which is maybe a bit unusual in the sense that each client using this system has their own database. (A client is like a company, with many users in it). So there is a master database which specifies, for each client, which database it must connect to. All clients databases are identical (except for the data of course).

I'm wondering how I should handle this... Normally, when an app consumes a Web API, you might have something like this:

    public class AccountsController : Controller
    {
        private readonly SomeContext _context;

        public FilesController(SomeContext context)
        {
            _context = context;
        }

        // GET: api/Files
        [HttpGet)]
        public IEnumerable<Account> GetAccounts()
        {
                return _context.Accounts;
        }
    }

Now, in the above example, the problem is that the Context has to point to different databases, depending on which client is requesting the list of Accounts. I'm not sure how to best tackle this. Would it be OK if the front end sends, with every API call, a client identifier in a query string? So every single controller action would have a ClientId parameter. And based on this parameter, the action would modify the Context's connection string on the fly, just before calling it? It just sounds terrible though - both from an implementation and a security point of view. The problem is that, as far as I'm aware, ASP.NET is stateless, so every time the API is called, the API will have no idea who this is?

Or how else could I do this?