What are the error messages about? If you're talking about exceptions—that is, errors which look such as “Object reference not set to an instance of an object”, those errors are expected to be read by developers only, and never be shown to the end users. This means that translating them makes no sense.
As a provider of an API, you usually don't have to bother about translations, would it be error messages or anything else. You provide data, and it belongs to the application which uses this data to show it through a visual interface which, often, would have to be internationalized and localized.
A few examples:
If your API has a date to send to a client, it would be formatted in a non-ambiguous, neutral culture format such as 2016-12-24T14:37:06.58247Z. Then, the application may show it in a format which is actually suited for the user, including, for instance, the day of the week, or the month in full text and translated into the language of user's choice.
If your API has a floating point number, it would be serialized to JSON as 1725.38, and then the app will show it, for instance, as “1.725,38” for a French user.
In very rare cases, you do have to care about translations. Sometimes, you don't translate the data, but send the translations separately (for instance as a JSON file which associated keys to values for a culture specified in the HTTP request). Or you translate the actual data. Or you send the raw and translated data side by side.
If your API belongs to those rare cases, the choice of presenting the data should be guided by the requirements and constraints defined by your product owner, or, ultimately, by the customers. If they disagree, it's up to the product owner to decide if you follow the ones or the others, or develop two APIs.