I am building a service where we need to create a new phone number to each new account and later act as its Whatsapp intermediary. So every new user can have their own Whatsapp number and see chats (and interract with them) in our external app. Basically a client for whatsapp numbers. Is there a way to do it with Twilio or Vonage? I tried to but it seems like it allows to build such functionalities only with one, WhatsappBusiness account. But it doesn't allow to scale new numbers programmatically.
Twilio developer evangelist here.
We do have an alternative process for creating accounts that service other businesses through WhatsApp if you are an independent software vendor or system integrator. However, it's still not an API process. I believe this is because there is an amount of back and forth between you, Twilio and Facebook to set up, review, and approve each business account and number.
The restrictive nature of this is on Facebook's side, since they have stricter rules for how WhatsApp can be used to engage users. So I don't imagine any partner will be able to offer this process entirely through an API.
Related
By default, Twilio trial accounts can only send SMS to numbers that are listed as Verified Caller IDs in the Twilio console. These numbers have to be added manually, and require a verification message before they can receive SMS. This is an excellent feature for development, as it prevents accidentally sending SMS to wrong numbers.
My problem, is that I am developing for a client whose account is already out of trial status. I don't want the software in development to be able to send text messages to any number, because there is a risk of sending dev messages to the client's actual customers. However, we need to be able to send to some numbers for testing. Is there any way to turn the trial behavior back on? That is, can we somehow configure Twilio to only allow sending SMS to verfied numbers, even if it is not a trial account?
If this isn't possible, I think I can query the Outgoing Caller IDs resource from my program to verify the recipient number against the list before sending. However, this puts the responsibility back on my development team, and the possibility for mistakes remains. I'd like to be able to block the behavior at the Twilio level.
This behavior is only applied for trial accounts, however I'll pass this feedback on internally.
You'll need to replicate this behavior yourself for your applications using an upgraded account.
As you mentioned, you can query the Outgoing Caller IDs to get the phone numbers you have already verified with Twilio and use that as an accept list.
However, for your use case, you can store and fetch the accept list using whatever way is most convenient for you, like in code, file, database, etc.
Depending on your needs, you could embed this logic directly into your app, or use a single shared library, or create a web API that all other apps have to use to send texts.
Good luck! We can't wait to see what you build!
Update after getting internal feedback.
You can create a new trial account, even with the same Twilio profile, which would give you promotional credits and the same verified Caller ID limits again.
The promotional credit should last you a long time for test scenarios.
I have been trying to personalize my messages and send in masses to my customers in google spreadsheet through whatsapp. Have been trying to work on this with an expert but it seems that currently they only allow twilio number which we have to buy from them. May I check whether any of you know when twilio will be able to enable non-twilio number(our personal contact number) for the whatsapp?
WhatsApp does not support certain uses cases, so verify this is this a promotional use case.
You will need to WhatsApp enable a Twilio number. Based on where you are located, porting your number to Twilio may be an option.
WhatsApp Commerce Policy
What use cases and businesses are allowed to use WhatsApp on Twilio.
I'm an indie developer and love the platform but have recently discovered that you can't buy phone numbers from a trial account. I've also seen that "sandboxing" is a deprecated feature and was hoping that something similar has been created in it's place. For someone like me money is tight and I'd like to get a basic app together before having to pay for the platform.
Is there anyway that I can test these platform features without incurring a cost?
Twilio employee here.
For development, we don't charge you until you upgrade. That said, to get you started, you get one free phone number when you sign up. It is 100% yours to do with as you wish.. with a couple limitations: You can only send SMS or place calls to phone numbers you've verified with us.
Also, once you've upgraded you can still do testing and development for free with our Test Credentials. The full details are on the site - http://www.twilio.com/docs/api/rest/test-credentials - but this is probably the most important bit for you:
You use these credentials in the same way as your live credentials.
However, when you authenticate with your test credentials, we will not
charge your account, update the state of your account, or connect to
real phone numbers. You can now pretend to buy a phone number, or send
an SMS, without actually doing so.
I have a client that needs to have its volunteers purchase an IAP (A data package that is downloaded), then somehow reimburse them. The problem is that there is no easy way to do this that I think Apple will approve of. Especially for over 1500 people. I've come up with several ways of doing this with their pros and cons, which one would be best to implement and does anyone have any other suggestions on how to do this?
1) Have the client send out iTunes gift cards via email. The IAP is $7, and you can't send a gift card less than $10. Also, they would have to send them one at a time, there is no way to send bulk. Not going to work
2) Create gift codes like iTunes gift cards. My client can purchase codes in bulk via IAP (so Apple still gets their money), and store them on my web server securely. I can then implement a system to send all the codes to a single email, or individually to multiple emails. Then the volunteers can use the codes to unlock that single IAP. This would be more work on my part, but easier for my client. Something tells me Apple probably would not approve of this method.
3) Create "Credits" that the client can purchase in bulk via IAP (so Apple still gets their money), then gift either the credits or send the IAP info itself to the volunteers via a p2p bluetooth connection created with game kit. This would be harder for the client, as they would have to send each "Credit" individually. But I think Apple would be more likely to approve this.
4) Have the client send me a list of UUIDs for each of the volunteers devices. I add the UUIDs to a secure list on my server. During the purchase the a check is preformed to see if the devices UUID matches one on my server. If it is, they are marked as "all ready paid" and given the IAP data. I don't know about this one, as the only way I can see the money transfer happening is myself getting paid directly, and Apple being left out (So they probably wouldn't approve of this. I have no problem giving Apple their 30% if I could find a way to get that to work with this.
I'd go with Option 5, and create my own IAP system. Much like Option 3, but bypassing Apple all together. Add a Custom URL Scheme to you application, give it to your client to distribute. When your app is launched by its Custom URL Scheme have it open to a promo code entry page.
Your client would be able to purchase/create codes as necessary via a website that you set up for them. You would then store the codes (or create an algorithm to check generated codes against), and validate the codes as the users enter them.
Then your clients users would enter their unique code and have everything unlocked/downloaded as needed.
I have done a similar set up with promo codes to unlock the full version of my applications so I could create my own promotions, without making the upgrades free for everyone by removing/altering the IAP.
Actually I'm developing an iOS application for specific mobile operator,
The app will be free , and some content need to be paid so the operator
need users to pay via Premium SMS or IVR (interactive voice replay),
But after make some search i found that Apple maybe will reject the app.
because the need all payment being done via there system i.e via in-app purchase
or paid Model .
What is the ways to solve this problem , and How can i achieve this (Premium SMS ,paid IVR) ?
The bad news is: you can't ship an app that is solely based on paid sms from within the app. As this article on arstechnica states:
Content providers can continue to offer outside subscriptions that are accessible via an iOS app, so long as no external links to outside purchasing mechanisms are built into the app. If subscribers can pay for content within the app, it must use in-app purchasing APIs, though content providers are now free to set whatever price they like.
If you really want to deploy paid text messages, you could integrate in-app-purchase with a high price. Additionally you offer paid text messages at a lower price(Users send a text message via their ordinary message app to a number you tell them via your web page or ad or any other way). So users will tend take advantage of the lower price and will send text messages. An obstacle will be, that Apple won't allow a reference to the cheaper payment method from within the app. So it depends, on how you inform your users about your app and payment methods.