Confirm what they are seeing
Ask for the endpoint, the time, the response code and the request ID if you provide one. Check your own logs for the same requests. Do not assume the limit is the cause until you can see the rejected calls.
Explain the limit once, clearly
State the limit, how it is counted and how the customer can see where they stand. Link to your documentation rather than rewriting it. A developer wants the rule more than an apology.
Look for the usual causes
Check for a loop with no backoff, repeated calls for data that has not changed, many small requests that could be batched and several services sharing one key. Fixing these often removes the need for a higher limit.
Give them code-level help
Suggest exponential backoff, caching and batching, and point to your example code if you have it. Be specific about their case. Generic advice reads like a brush-off.
Decide on a higher limit
If their use is legitimate and growing, say how limits are raised, what you need from them and how long it takes. Pass the request to whoever owns that decision, and tell the customer when to expect an answer.
Record it for the product team
Tag the ticket. A pattern of complaints about one endpoint may mean the limit, the error message or the documentation needs work.