From glancing over you do NOT connect to your specific ID endpoint
see embolded snipped part at bottom, or check the code parts for other languages, where account info is given to client
presumably to enable correct connection (which perhaps is only mangled URI REST endpoint for easy routing response)
Perhaps easiest to check the sources of the clients in Javascript (or C#, Python, Java...) how they work
Use the "other" environment you feel most at ease and with luck already installed on one of your (virtual) machines

Whenever possible communicating via foreign API to internet endpoint I try to have alternate API resolution
helps a lot when API changes or with other endpoint troubles - at the expense of supporting more API and
blabby logging and end user information screens.

But recent use cases like log4j weakness might result in JAVA endpoint stopped for a week or more,
while other parallel backend in PHP with RPC keep running....

Used a dynamic OOP structure with
object "sources" including connect info,
dynamic "translator" to create msg for canal
dynamic "routebilder" to include connection or endpoint info
using XmlHTTP as Rick back then had not enough security support, which almost certain he has now
(this was dawn of century, FTP often unsecured and certificates seldom used but for gov identification)

Probably better adressed at West-Wind directly...

regards
thomas
>curl -X POST https://api.twilio.com/2010-04-01/Accounts/$TWILIO_ACCOUNT_SID/Messages.json \
>*!* --data-urlencode "Body=Hi there" \
>*!* --data-urlencode "From=+15017122661" \
>*!* --data-urlencode "To=+15558675310" \
>*!* -u $TWILIO_ACCOUNT_SID:$TWILIO_AUTH_TOKEN


>lcResult = loHttp.Post("https://api.twilio.com/2010-04-01/",lcJson)