I believe API keys are actually an older convention for auth than JWTs (which were only standardized in 2010); you certainly aren't re-inventing any wheels to use them. This scenario definitely seems ripe for using them, whereas I think JWTs would actually add quite a bit of needless complexity.
JWTs are especially valuable for certain authentication and/or authorization scenarios, but I don't think any of them apply here. You're presumably not separating authentication from authorization (JWTs allow one party to authenticate a user and then another party to provide - or deny - service based on that). You're keeping a small pool or users and presumably will have few active connections and request rates, so cutting one database (or, realistically, data cache) lookup per request isn't likely to be urgent. It doesn't sound like your partners will likely expect multiple tokens each with a minimal set of permissions - it's more secure in some scenarios, but definitely more complicated to implement - and you could do that with API keys anyhow.
On the other hand, JWTs introduce significant risks. JWT-parsing libraries need to be secure against a number of attacks that just don't come up with API keys (those have their own risks, but they're mostly well-known things like SQL Injection, brute-forcing, or timing attacks). JWTs require generating, storing, using, and hopefully rotating cryptographic keys; they may also require distributing them if you're separating the authentication provider from the service provider. JWTs are hard to revoke, so they're usually made short-lived, meaning you need to support some other authentication token (like a DB-stored refresh token) or low-friction auth method, at which point you might as well use the API key anyhow.
Another option (which may or may not be suitable for your customers or API) would be to use TLS client certificates. These can be more secure than either of the approaches discussed (the control and simple processing of individually issued and revoked keys, the built-in expiry and impossibility to brute-force of JWTs, and unlike either you avoid ever transmitting the actual secret over the wire even within a TLS tunnel and "accidentally send the token via plain text" isn't even a meaningful risk). They also have drawbacks, though (requires handling key material, makes enrollment more complicated, makes it harder for an individual user to enable access for multiple devices, rotation can be more complicated in the event of a compromise, users are likely just less familiar with them). I wouldn't even mention it except that you're expecting a very small number of users and a working relationship with them.
