Skip to content

HTTP Proxies

Most integrations are asynchronous, and run in the background. When speed is a factor (for example, when a stock update needs to go through), you can use Webhooks to trigger the update for a particular entity. But sometimes it is both time-critical and needs a response. A stock-update doesn't require a response beyond updating the stock, but there are a few use-cases where another system needs to get data from Alumio.

Here are a few examples:

  • A customer in their 'my account' webshop clicks on the 'download invoice' button. The webshop needs to get the invoice from the ERP system, and show it to the customer. If you want to implement this with Alumio, the realtime result of the call would a PDF.
  • The webshop wants to get an explicit response accepting the order they are sending by API. You can't dynamically build the response with a Webhook in Alumio, so you need to use a HTTP Proxy.
  • Some system needs data from the ERP, which the ERP only sends once every 24 hours by FTP. Since the other system can't access this system real-time, you'd need to use a Storage in Alumio to store the entity every 24hrs, and return it to the system when requested. The response is dynamic, so you can't use a Webhook.

Alumio likely meant the HTTP Proxy to be used as an 'in-between compatibility layer' - basically when System A has a way to request stock, but System B's API works differently than System A expects. This is why Alumio's system requires you to do a call to another system in a HTTP Proxy, even though some use-cases (like the last one) don't require it.

How do HTTP Proxies work?

When you create a HTTP Proxy, Alumio automatically creates a URL for you. You can send every possible HTTP request to this URL, and Alumio will forward it to the configured endpoint.

There are 4 'stages' in the HTTP Proxy:

  1. Receiving a request
  2. Sending a request to System B
  3. Receiving a response from System B
  4. Sending a response to System A

The 'data' goes through these four stages, and can be transformed after stage 1 and after stage 3. You can use Entity Transformers here, including requests to other systems, checks in storages, etc.

For cases where you don't want to talk to another system, you can 'fake' a call by simply calling Alumio's Internal API to run a transformer. This means you retain all data (since that is returned as the dataset).