When you write wrappers for APIs how do you handle usage errors?

Think wrapper vs adapter vs bridge from a design pattern point of view. You might have a new perspective and find your answer from there.

E.g. Adapters and Wrappers from Andy Kramek and lots more if you google.

A lot of the answer depends on the API you're wrapping, the target audience for wrapping it and the language you're using. If you're exposing an API written in one particular technology to a different technology, there'd be value in smoothing out some of the common problems in the wrapped technology. For example, .NET wraps up some Win32 APIs, like CreateFile() to read a file. It's quite easy to use the wrong parameters for CreateFile(), so if you want to do something simple like read a text file, there's a utility function to achieve just that operation, rather than just encapsulating each function with a wrapped version.

Checking the input parameters for empty/null/out-of-range before calling the wrapped API would have value, but not if its at the expense of performance - better to decipher the problem when the wrapped function fails.

Exceptions, if available in your wrapping language, would be appropriate for conveying errors to the caller.

You should never trust your caller, who is calling your API. You need to implement tight checks on the inputs. And always validate the request object before sending it to further processing. You can use the approach of giving a response object to the caller. Having a field of response code and response description. And you can standardized these response codes for your application.