My organization is using the Twilio SDK in C# to sms and mms messages with a single long code. We have several teams in several different departments using it for various purposes and are looking to track how much of the bill belongs to each team. Each team has an API Key that they are using to authenticate their calls to send a message: TwilioClient.Init(apiKey,apiSecret,accountSid);
Is there anyway to see in the sms logs a breakdown of which API Key was used to send messages?
There is not. You can however use sub-accounts which are logical containers of resources, and then the usage API to determine usage by subaccount.
Related
I want to configure the Twilio autopilot functions to persist the user inputs and use them across the chatbot application. Is there any provision for creating functions from our backend application or are there any other provisions for getting the values in the memory so that I can use them thoroughly across my client-side chatbot application?
Have you taken a look at Twilio Sync? You could persist some information in there, json format, and retrieve it from any other Twilio validated app or function. You can subscribe to the different item events as well, to show up-to-date information if you'd need it to change.
https://www.twilio.com/sync
The current youtube API quota is 10,000 units/day.
So what if I created an app and this app has 100 copies installed on different 100 devices and all of them use different IPs, would the quota be 10,000 units/day for every device (1M/day) or the 10,000 units would be distributed among the different copies?
Note that the requests will be executed on different devices. this is an embedded app., not a cloud one.
10,000 units/day is project based, not user based. IP address won't affect anything.
As you can see from the above image on the Queries per minute per user is user based, and detected via ip address, sending the quotauser parameter along with the request or sending an authorization header containing an access token.
In order to get around your 10k quota in this manner you would need to create 100 projects on google developer console and create credietnals for each of those projects and then each project would have 10k quota. However the drawback would be trying to get 100 projects though the google verification process.
You could just request an extension of your quota if you need more quota. 😊
Additional Clarifications
API key Used to access public data only and identifies your application to google
Client id and client secrete used to create a access token, will identify both the application and the user to google once a user is authorized and you are sending an access token authorization header with your request.
The quotaUser and userIp parameters can only be used for anonymous requests with some Google apis this has changed recently i am not sure if it still works with YouTube api private calls. userIp allows you to send any ip address with the request, and QuotaUser allows you to send any string for example your internal user id for the user making the requests. In the past this allowed for some hacking / work around for the per user quotas.
None of the above information will really help you as the quota you are trying to get around is a project based quota and not a user based quota. Its detecting the project associated with your client id / api key (depending upon what you are using) changing the IP or generating a new client under your project isnt going to help.
Really just request more quota
There are two ways an app is identified by the API:
the API key that the app uses when invoking the API endpoints (for reading only public data), or
the credentials data (i.e. access token) the app makes use of when calling in various endpoints (for reading only public data pertaining to any YouTube channel, or, otherwise, for reading/updating/deleting public and/or private data pertaining the YouTube account/channel that granted permissions of operation to the respective app).
Therefore, from the point of view of the API, it doesn't really matter if you are running N different instances of your app (i.e. programs running on concrete computers). The API accounts for the quota consumption of a given project created through Google developers console.
In this context of an app (as a concrete program) running on several machines that share API keys and/or credentials data, I recommend warmly to get familiar with the content of the DTOS specifications.
The JavaScript chat client SDK is missing some functionality that the REST API has, like list users. Should the 1st person chat client be using the REST API as well to supplement gaps in the client SDK or just in general? Or is it strictly for backend management?
Twilio developer evangelist here
The Chat SDK itself doesn't give all of the same access as the REST API because that would put that access directly in the hands of all users of the Chat SDK. Restricting things like listing users of the app to the REST API means that your application has greater control over those functions and can restrict access or use it only in specific circumstances.
As we've discussed in your other question, how you actually manage things in your application, whether it is by calling to the REST API or storing data in your own user database, is up to you and depends on what will work best for your application.
I retrieved an access token from my server and have connected the JavaScript SDk chat client like so. I have created a channel like so. The next step I'd like to invite a user like this. In that example they invite the user 'elmo'. Where do I get 'elmo' or how do I present the user with a selection of possible 'elmo's? The client sdk has no list users functionality.
Edit:
It looks like the REST API has a list users method. But can't find any examples of it used. Should the 1st person chat client be using the REST API as well to supplement gaps in the client SDK or should it get the identity from backend? Our team has different interpretations of the docs: twilio REST API is strictly for backend vs. twilio REST API can and should be used any where. Moved to twilio REST API: strictly backend?
Twilio developer evangelist here.
In my opinion Twilio's Chat API should not be the central source of truth of the users in your system. I don't know anything more about your application than what you've written here, but I would expect that you have a user model within your own system that you have used to generate or create an identity that is then used by the Chat API as well as how your user logs in to your system. I would then use that user model to connect users and provide their identities so that they can join chats together.
jut for a background, I'm building a poc of twilio based video chat contact center and I've came upon one issue. Most of the people using the service will be anonymous customers, no logging / authentication here. Looking at the twilio api, once I produce a Token with VideoGrant I loose all control of what the javascript client does with it, for example, someone can modify my JS client to create their own room, instead of joining the one assigned by my app.
Is there any way to create VideoGrant which would allow only joining a room, preferably a single, selected room?
There is a mention of Room Events in the console, but I didn't see any docs on it, maybe it would allow to catch rooms creation and kill the unknown ones, btw is there a REST api for rooms? nothing on official REST api docs again.
Sorry if the questions are a bit vauge, I'm aware that they might not meet SO standards, but I know that few Twilio developer evangelists are active so maybe you guys can propose some best practices here or just point out to the right docs if I am dumb enough to have missed them.
Lukasz,
Rob Brazier here, PM for Video. In the next few weeks we'll be adding a new grant to the Video section of our Access Tokens that allow you to lock down access only to a specific Room.
The basic flow will be:
User visits your site.
Your app server decides what Room they should connect to.
Your app server creates a Room using whatever identifier you like as the name (using the upcoming Video REST API).
Your app server generates an Access Token with a grant for the specific Room created in #3.
Your app server returns that Access Token to the client.
Client connects using the provided token and is joined to the specified Room.
Let me know if this is clear. Thanks,