I understood your setup as follows: You have a secret master key $K$, and generate $1000$ shares $(k_1, k_2, \ldots, k_{1000})$ using a $2$-out-of-$1000$ secret sharing scheme. Each user $P_i$, as well as the API, gets one share $k_i$.
But then, any two users can combine their shares $k_i$ and $k_j$, reconstructing the master key $K$. Having done this they can e.g. generate additional shares, allowing previously unauthorized users access to the API. Mind that, by Kerckhoff's principle, parameters such as the field you are performing secret sharing over are known to an attacker.
There's also the secondary issue that this does not allow you to identify users. At some point you might want to revoke some user's access, or impose rate limits. Doing this would require keeping track of the users' shares on the server side, at which point the scheme degrades to a regular API key setup.
This seems like an XY problem. What are you trying to achieve? What prevents you from using more traditional API access control mechanisms, such as regular ('symmetric') API keys, or mechanisms such as OAuth?
If you want to avoid having to store credentials in your database, then a basic approach would be to only store hashed API keys - using a cryptographic hash function such as SHA-256 - in your database. When the server receives a request with an API key it hashes it in memory, and compares it to the hashed entry stored in the DB. This prevents leaking API keys if your DB were to be leaked.
