In Twilio, Both of the APIs are essentially made for programmable messaging, then what exactly is the difference?
Both of the API's can be used for A2P messaging, integrating with Bots, extending communication use cases.
Conversations API is said to have the advantage of integrating multiple channels into one application, but so can messaging APIs. If both are not mutually exclusive, the distinction is not very clear.
Conversations API is used for 1 to 1 (or multi) communication between users: send and reply.
This is more suitable for customer support and customer relations.
Programmable Messaging API is used for software to user communication: alerts and notifications.
This is suitable for appointment remainders, alerts, delivery notifications and sending temporary web tokens. Also, it is made for a larger scale than Conversations APIs.
Related
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.
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.
Just in the title. If a company is using Skype for Business with their Office 365 subscription, are the contacts in skype for business the same contacts available by the Graph API?
My understanding is currently the only way to access Skype for business data from an API standpoint is through the UCWA 2. And that the graph is not reflecting any data for S4B. This is also why those are two different set of permissions when you declare apps in the AAD portal.
One of the reasons behind that is probably because when using the UCWA you need to talk to different resources and endpoint for Discovery and Grant flows before getting to the data.
Another one could be that UCWA provides streaming and some kind of notifications capabilities (status update, messages) which the graph doesn't support right now.
I really hope the S4B endpoints come to the graph at some point, things are going to be simpler.
Is there a way to achieve twitter like push notification via AWS SNS?
SNS send notification to the user when something is happen him or her?
As i know the best way is to create a topic per user.
When user relate event happened,we publish a notification to the topic.
As AWS described the max topic number is 100,000 per account currently.
What if i've 1,000,000 users, it will not work.
Is there a more scalable scheme?
beeth0ven,
SNS supports publishing to a Topic of subscribed device endpoints or direct publishing to individual endpoints. In your case, you'll want to implement direct publishing to each individual endpoint. This allows more control and personal engagement but also means that you'll need to manage those endpoints in your own database and associate each endpoint to a user of your mobile app. Instead of publishing to a TopicArn, you'll publish individual messages to a TargetArn, which is the SNS Platform Endpoint that represents an app and mobile device. TargetArn is also the same call to send an SMS message to an individual phone number.
SNS Publish CLI: (see --target-arn)
http://docs.aws.amazon.com/cli/latest/reference/sns/publish.html
Direct Publishing via the Console:
http://docs.aws.amazon.com/sns/latest/dg/mobile-push-send-directmobile.html
I'm doing some feasibility work for a mobile app. We'd like to send D2L notifications directly to the mobile app (not via SMS or email).
We'd like to know if D2L's notifications system only notifies via email or SMS, or is it possible to configure it to send notifications via other channels, such as a message broker, ESB, etc.?
I've read D2L online doco; it's not clear if the system can be configured for anything other than email or SMS delivery. If it is only email/SMS, is it possible to use the REST API to get notifications for a student? That way we could have the app 'poll' for notifications.
Thanks,
Tim.
The D2L learning platform as delivered currently can only deliver notifications to SMS or Email endpoints. It may be possible to expand the list of endpoints available through a customization services engagement with D2L. The Learning Framework API does not currently provide any direct access to the notifications themselves, only to the association between message types and endpoints.