In the simplest way, you could enable HTTP Basic authentication on your side. Provided that you've enabled HTTPS on your server, and made sure the clients were configured with the
https:// URIs (avoid relying on automatic redirects, especially with HTTP Basic in fact). Just give each registered client a username and a password.
Most clients should support this form of authentication. If your client is a PHP server, setting the
CURLOPT_USERPWD parameters should do.
It's also quite common to use an API key (based on some UUID, for example) as a query parameter for some APIs. How convenient this is may depend on your side of the code. Overall, it's quite equivalent to Basic username/password in terms of security (except that you may have to map the key to a username).
If you want to use public key authentication, use SSL/TLS client certificates. This is more involved. You may have to create your own CA for this (this can be done in such a way that the key generation is done in the user's browser, but this can still be inconvenient).1
The downside is that the users may have to convert certificates from one format to another for them to be used.
Either way, if SSL is used on your side and you expect them to paste some PHP/Curl code, they may still have to do a bit of configuration. At least,
CURLOPT_SSL_VERIFYPEER should be
CURLOPT_SSL_VERIFYHOST should be
2 (default) and
CURLOPT_CAPATH should point to a directory containing their trusted CA certificates. Where this is may depend on their host.
1 It's also possible to turn an SSH RSA key into a self-signed X.509 certificate, but that's quite technical (and would also require some work on your side). Other public key authentication mechanisms (possibly based on SSH keys) on top of HTTP would be up to you to create, which is generally a bad idea (hard to get right on your own). It's certainly not worth the effort, since HTTPS with client authentication would provide you with something proven, and already supported by existing libraries.