There is naturally more than one way to skin this cat, and we could argue over the finer points of this question all day but the basic process looks like this:

There is naturally more than one way to skin this cat, and we could argue over the finer points of this question all day but the basic process looks like this: 1 - Some business process that assigns a customer an API Key and allows them to setup a Webhook destination on their own server ( mapped to their domain name - such that IP address management is a customer burden ). 2 - The customer hosted Webhook destination the user inputs is what your platform uses as a callback to inform the users system of some change. 3 - Requests to your system are made via HTTPS POST such that the API key is included in the body of the POST request ( likely some JSON ). 4 - The request is processed on your side, the API key is validated and used to look up the customers Webhook ( callback ) URL. 5 - The requested action is performed and some JSON structure is POSTed to the customers HTTPS Webhook ( the JSON format is a documented agreed on data structure - the customer is expected to parse this ). Note that: Customer API Keys are assigned by you, stored in your database such that they can be mapped to a customer hosted URL. An API key in this case might be a CustomerID and some significantly complex auth token such that the two of them in combination represent a significant burden to guess. Customer API Keys are presumed to be stored on the customers machine and are NOT publicly accessible ( not stored in /var/www/secret_keys/myApiKey.txt ). Customer API keys are sent via HTTPS in the body of a POST request - they're not getting logged anyplace and the data is encrypted during transport. The use of a Webhook ( callback ) is not strictly necessary - but since you don't mention how long a request might take its worth considering making the whole process asynchronous. The customer request could just as well return the resulting output over the same connection that initiated the request in the situation where the request takes a reasonably short amount of time. A good example of something like this in action is https://www.twilio.com/sms https://www.twilio.com/sms - the Programmable SMS product. This product makes use of a process like the one I describe here and it's a great example to emulate. For a learning experience, the docs are good, the API is clear, its cheap to play with and generally a nice tool.