I'm using Twilio REST Api to create a call programmatically, with call-status and recordings web-hooks wired in. The web-hook POST requests are currently hitting the server but failing on me because there is a requirement for a custom header entry.
I want to be able to pass my custom headers (that needs to be sent in the upcoming web-hook request headers) when I create those calls with the web-hook urls. The custom header should have dynamic value.
I have something like this:
call = #client.calls.create(
to: "+1XYZ",
from: ENV['TWILIO_ACCESS_NUMBER'],
twiml: '<Response><Record /></Response>',
status_callback: ##callStatusHandler,
status_callback_event: ['answered', 'completed'],
)
When I create such calls, I will have access to sessionid with a dynamic value, say my-session-value. Now when the webhook request comes in, I want sessionid = my-session-value in the header.
Is there a way to achieve this?
If you need to add your own custom headers, you can try to proxy your requests through some other logic before it hits your application servers. This was a past in the post around forking webhooks you can look at and see it it can be modified to meet your needs.
Creating A Twilio Function to trigger 2 webhook endpoints (Autopilot & FrontApp) For Incoming SMS
There is an example of passing a custom Axios HTTP header below:
Make a Write Request to an External API using urlencoded data
Related
I was reading up on how to create a telegram bot and I see that to set a web hook you use the GET http method. I assume that your link will be stored somewhere on telegram servers.
So now my question is:
Why not use the POST http method? What is the advantage of this design of using GET http method in this case rather than POST http method for something that pushes data?
Bot API supports GET and POST HTTP methods both. It's up to you what to use. (See this or this). I think it makes the API easy and fast to get started with.
For the sake of simplicity one might choose a simple GET request to set a webhook - Put together a Url with some parameters and call it in a web browser, done! Webhook is now set.
Still it is possible to do the same with a POST request (and you can argue it is the preferred way to do so). But it would need tools like Postman, CURL or some browser extensions.
I am using the Call Resource from Twilio API and I need to get the extra parameters I have passed to calls I have made. In my application I pass the extra params with query params such as .../Calls.json?foo=bar. These extra params hold information for the client and such. However when I try to get all the calls from Twilio API through https://api.twilio.com/2010-04-01/Accounts/AC789cf80fc3910717722e21f7714c5b98/Calls.json I get all the calls but there is no trace of these extra params passed to the call. I was able to get some of these params in the Notifications resource where it included the Request URI I made, but the Notifications resource did this only for error messages. What is the way to do something like this? Should I include status callbacks and check for each one manually?
These query parameters are sent to your application, which consumes them. This is how you would access them, not as you found, via the historic /Calls resources logs.
How to Share Information Between Your Applications
Passing Custom Information via Requests to Twilio
I am trying to build a Custom Connector in the Power Platform to connect to the BMC Helix (formerly Remedy) system to create work orders and such. I am using OAuth2 and was given a callback URL, auth URL, token URL, client ID and client secret.
I went to create a connector from scratch. I populated the fields, but I wasn't sure what to put for the 'Refresh URL', so I used the token URL there too.
I am trying to accomplish testing this connector and my successful test would be to get a JWT from doing a POST to the /api/jwt/login endpoint of BMC Helix. It should return a JWT which I can use to make subsequent calls.
Upon testing this, I go to create a connection, but a window opens (which I believe should be a prompt for authentication), but instead it contains an error saying 'unauthorized_client' coming back from the BMC Helix system at the /rsso/oauth2/authorize endpoint. It also contains a property within the URL of redirect_uri = https://global.consent.azure-apim.net/redirect.
Is there something on the Helix side I need to further configure? Not sure why I am getting this....
It sounds like you need TWO METHODS in your connector. A POST to call the token server, a GET (or another POST) to call the API (using the token received from Call 1).
One approach I've successfully used in the past is:
Use Postman to get your token server call working with OAUTH
Then use Postman to get your subsequent API calls working with the token appended
Save both requests to a single Postman collection
Export the Postman collection (as a V1 (deprecated) if I recall correctly)
Import this collection into PowerApps Custom Connector (create new/import from Postman Collection)
You'll have to massage it a bit after import, but it will give you a good headstart and you're starting from a known-good place (working Postman calls)
Good luck!
We have implemented an IVR system which also redirects calls to a Call Center. The Call Center wants us to send relevant information in the custom SIP Header so that the IVR can pass custom information that will be useful to service the call without requesting the information entered in the IVR again.
I have tried to find documentation which clearly explains what is needed to be done but have had no luck.
Is it as simple a adding custom headers as SipHeader_X-headername=headervalue as part of the Voice response as mentioned in https://www.twilio.com/docs/api/twilio-sip/sip-twiml
or something else is required like the SIP URL as mentioned in https://www.twilio.com/docs/api/twiml/sip
Any direction/help will be really helpful.Thanks in advance.
UPDATE to question :
Configured an URL in Twilio to direct calls.Using Java based Microservice app using Spring Boot to service the URL calls. The below code snippet contains the Dial to the CSR.
String say = null;
Redirect redirect;
VoiceResponse.Builder builder = new VoiceResponse.Builder();
say = messageSource.getMessage("You are connecting to CSR", null,
Locale.ENGLISH);
builder.say(new
Say.Builder(say).voice(Voice.ALICE).language(Language.EN_US).build()).dial(new
Dial.Builder().number(new Number.Builder(number).build()).build());
response.setContentType("application/xml");
response.getWriter().append(builder.build().toXml());
Sounds to me like you are dialing out to a SIP endpoint so your extra parameters should look something like this from the docs you linked to:
$dial->sip('sip:jack#example.com?mycustomheader=foo&myotherheader=bar');
The documentation Twilio has on their website doesn't contain raw POST bodies, and it has conflicting sources on how the attributes are named/which attributes are included in the body.
Field names and their casing don't match:
https://www.twilio.com/docs/api/twiml/sms/twilio_request#request-parameters
https://www.twilio.com/docs/api/rest/message
Should I expect Message Resource type for all of their POST requests to our URLs(Status Updates and Message Responses) ?
Should I expect only the field names advertised on their Twilio's request page?
Do they provide all parameters or any additional parameters in their request not advertised on the documentation(Twilio's request)
I'm assuming they would also provide "MessageStatus" field in their POST requests, but I don't see it on all documentation pages.
The headers in their requests?
Twilio developer evangelist here.
Of the two pieces of documentation you are referring to there, only one is about the request Twilio makes to you when you receive an SMS message. The other is the Messages resource of the REST API.
So, in answer to your questions:
1) The attributes you receive are the ones described in the request documentation. If you want to confirm this, then I recommend setting your webhook URL to a Request Bin which is an easy way to inspect a webhook request like this. Alternatively, if you are using ngrok to test webhooks locally, then check out the ngrok dashboard which also allows you to inspect (and replay) requests.
2) Yes!
3) There are no extra parameters that I know of.
4) MessageStatus is not included. You can look it up using the Messages resource, but in my experience at the point of receiving the webhook the status is "receiving". Once you are done processing the webhook the status changes to "received".
5) The headers are mostly standard. There are extra ones for security, such as the X-Twilio-Signature header. Again, I recommend inspecting a request with Request Bin or ngrok to fully understand the entire request.
Let me know if this helps at all.
Edit
The Content-Type header for POST requests from Twilio is application/x-www-form-urlencoded.
In a message status callback, the parameters are all the usual parameters plus the MessageSid, a MessageStatus, and if relevant an ErrorCode.