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
Related
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.
I have implemented a RESTful API with few resources, for example:
/products/
/products/1
/products/2
/categories/
/categories/1
/categories/2
etc.
Now, I have been told that the app should mainly work offline, therefore I need to get all the data from the APIs and store it locally.
Since I am not providing a single chunk of data but there are different resources URI that needs to be called in order to get all the data I was wondering if this could be a problem.
How does this work? will there be many HTTP calls or one call will do everything?
What is the best approach in this case?
Are these endpoints in themselves?
/products
/categories
It's a pretty well established convention for those to return the entire collection. You could even add some request parameters for filtering etc.
Each URI represents single peace of data. The main idea of REST, instead of having randomly named setter and getter URLs and using GET for all the getters and POST for all the setters, we try to have the URLs identify resources, and then use the HTTP actions GET, POST, PUT and DELETE to do stuff to them.
So, using AFNetworking, for example, you get all benefits of this architecture.
Download model could look like:
Ask server for specified resource by get request
save response in background thread
ask for new peace of data
Of course, if you do not have ability to make new endpoint, that will download all stub, you must download it separately for each:
/products/
/products/1
/products/2
/categories/
/categories/1
/categories/2
Setting up your endpoints in this way will allow for a user of your app to retrieve a single product/category or a list of products/categories.
Here's what each of these API endpoints should do when they are called.
/products - returns a list of products
/categories - returns a list of categories
/products/:id - returns the product with the specified id
/categories/:id - returns the category with the specific id
As far as allowing the app to work mostly offline. The best approach is to do some caching on the client (app) side. Every time a call is made to one of these endpoints for the first time, the result should be stored somewhere on the client side. The next time that same request is made, the data has already been retrieved previously, so therefore no network call needs to be made and the app will work offline. However, the first call needs to have a network connection to be made.
This can be implemented with a dictionary, where the key is the request (/products, /categories/1, etc.) and the value is the result that is returned from the API request. Every time a request is made, your app should first check if the data exists already on the client side. If it does it does not need to make a network call to get it and can just return the data that's present on the cleint.
In the twilio web interface, when I look at a specific call, I can see all the associated requests under the request inspector. Is there any way to retrieve this data via the REST API?
Specifically, I'm trying to retrieve the 'Digits' parameter to see what a caller dialed in response to a <gather>
Twilio evangelist here.
There is currently no way to download the entire HTTP request/response using the API. This is something you would have to log yourself as the call is occuring. If you save the call sid at the same time as the Digits, that would allow you to tie those digits back to a specific call.
Hope that helps.
I'm trying to understand how webhook works. My understanding is that its the ability to connect two different applications. If I submit a webhook with url
localhost:3000/receiver
to one application, and I have my application with a method
def receiver
end
I was wondering if I don't know what the callback is from the webhook would be, how would I capture data? How do I save any JSON data thats communicating with my application? I was thinking maybe save some file to see what the objects are, but I'm still fairly new and not sure how to capture JSON data?
Thanks
If you are sure that the webhook is returning a JSON, you can so something like this
data_json = JSON.parse request.body.read
Sure, a webhook a is tool to sincronize two apps
You HAVE tou know the structure of the incoming json, because you need to get the info inside
By definition a webhook is sent by POST method, so you can capture it just inspecting the body of the petition, i.e.
webHook = JSON.parse(params[:something])
Your would try with github web hooks and publish your app in heroku, the api is very well documented and there are many examples.
So a user calls a Twilio phone number. Twilio looks for a voice_url attached to that number (from their dashboard) and sees some XML with instructions on how to handle the call. The XML file also has an "action" parameter that points to a url.
Ideally, this URL should be able to retrieve parameters sent by Twilio and save them to a DB. This is where I'm stuck; how can I see which parameters are sent and how can I save them? I'm assuming the URL in the "action" parameter points to a controller?
I'm using the twilio-rb gem.
Some relevant links:
http://www.twilio.com/docs/api/twiml/dial#attributes-action
http://www.twilio.com/docs/api/twiml/twilio_request
When Twilio makes a POST to the URL mentioned by the Action parameter, it will send all of the attributes mentioned here: http://www.twilio.com/docs/api/twiml/twilio_request.
You should create your own route and controller for responding to the incoming Twilio request. When Twilio makes the request, you should be able to get the variables out of the POST request like any POST request. See for example How to access POST variables in Rails?.