It may become necessary to make a request from a domain external to the Twilio project. To support Cross-Origin Resource Sharing, CORS, responding to OPTIONS request is necessary. To achieve this consider the following example:
The above code relies on the assumption that all OPTIONS requests will have no request body, event is an empty object. This assumption breaks down when dealing with GET requests. A GET request will have no request body. It is possible to support GET, but it would require duplicating the work in both the OPTIONS and GET. I would suggest sticking to CORS-enabled POST request for Twilio Functions that need to be accessed outside of the Twilio environment.
Calling Other Twilio Functions and Assets
Twilio Functions have access to the Runtime Client which provides access to Functions, Assets, and Sync. For now let us ignore Sync and focus on Functions and Assets. A typical Twilio Function will export a handler method. Using the Runtime Client we can get the path of that function and proceed to load that module and call:
A or B
This method has helped in numerous Studio cases where two paths converge and only one value will be present in the Twilio Function call. It handles both JSON and raw data values.