Would it be possible for an account stats and configuration API? I looked through your site code and it seems like there is a lot of JSON like stuff. I think I'd be able to do some fancy text mangling to get it, but an actual API would be a lot more handy.
Some things I could imagine I would use such a feature for...
- Event-based account changes. E.g. don't allow texts or calls after 9pm for your teenage daughter.
- Easy usage data exporting for presentations, records preservation, etc.
Thanks,
Josh Erickson
23
Comments
Sweet idea Josh... that would be awesome. I'm going to mark this as 'Not Planned'... only because I want to be upfront and clear about what we're up to and I don't want to give any false hope.
Lots of stuff is happening though... so it's not outside the realm of possibility... especially if we see demand form the geek crowd.
-Ben
I just want to register my strong interest for this.
I hope Ting adds this as well.
I know this is marked as not planned and an old topic but I want to restate that I think this is a fantastic idea. Realistically it probably has a very limited reach, but as I'm reworking the Android app for the new dashboard I'm wishing ever more that there was an API I could use.
Hey Brian, no need to apologize. Just because we mark something as "Not Planned" doesn't mean it's not still up for discussion.
I'm warming to the idea, but there are still SO many other things we can do to make Ting even better for "normal people" (i.e. people who don't know what an API is) that I'm not sure when or if we'd get to this in the foreseeable future.
I could see a pretty big community growing around this. Depending on what all an API is capable of, you usually find that people come up with some really cool stuff that wasn't previously even thought of.
Shoot, I could do some cool integration on the TingUsers.com forum.
I understand that Ting has said no for now but maybe we as the geeks can help. I know we dont have access to thier systems or data but we can knock out some of the planning stage and maybe that will help them put something together. Maybe we can put together an API doc of the calls we would need and the data that shoudl be returned. I know as a developer the planning stage can be very time consuming. I personally prefer JSON as a data format.
Example:
1. getAddress(apikey)
2. getNextBillDate(apikey)
etc.
Not sure if it would be the motivation needed to get an api built but Ting is great about supporting us. I would guess that Ting is more concerned about building it secure over the calls themselves. They would want to make sure that the API couldn't be abused to gain access to thing you shouldn't. I would suggest a checkbox option in the account that defaults to off that turns on and off API access to that account. Even better would be an API key in the web admin that a user could copy/paste into the android app that give access that way the app never knows the account credentials. Each user would have a different API key in their admin.
That makes sense. Given that, would you guys object to a third party read only API? It's based on an idea Kevin posted for the Android app. Basically have my server sit between the app and your website to do all the heavy downloading and data squishing and then delivering the ready to go data to phones.
Important requirements for that idea:
Pros
Cons
The more I think about this approach, the more I generally like it. It would make it much easier for me to maintain the Android app and deliver the best experience for those users. I think I could put it together pretty quickly. I know Ting can't and won't officially support something like this, but I would prefer to do it with approval.
Keith: We're always happy to hear feedback and suggestions and I would't discourage discussion of what at Ting API might have in it, but just so you know, we eat sleep and breathe APIs already. Our whole business is built on APIs including public ones like the OpensSRS API (13 years old now and definitely due for a major rethink).
Brian, I don't think you should go down that path. No matter how much we love and trust you I'm not sure we could ever support or encourage customers to share their log-in credentials with a 3rd Party. Just too many chances of things going wrong. Sorry.
Thoughts based on Keith's post
The API Key is a good idea. My API could use that instead of credentials. That way if anything ever went bad the user could just request a new api key and I couldn't access anything anymore.
Also, if I put together the API it could still be hosted by Ting. I know they have talked about setting up other php resources for the Ting Army and this could fit in with that. That would give them ultimate control over the end product. Though if they're hosting it, it would be a little silly to be doing page scraping...
Brian, sort of similar to what Ken said but if they are going to host something I'm sure they'd just write the full API. Other than that, we'll just have to stick with the screen scraping method. At the very least you could write your own deal to do what we were talking about. At least you'd trust yourself with your own credentials, lol.
I would trust myself, but the only thing I need it for (right now) is the app and I don't want to take that approach without general approval. I'll keep scraping and fighting with Java.
Ken: I have been using OpenSRS since the very early days (2004?). I know you guys know your stuff. I was just trying to make a suggestion on how we as a comunity could help without having direct access to your systems. I understand about company priorities. I'm a developer and have priorities myself.
We're in violent agreement Keith! Thanks again for everything!
You know, an API for *sending text messages* would be a fantastic addition.
Ting's 1/4 cent each is far cheaper than Twilio or really any other SMS gateway service I've seen. You could very easily get developers to use your service. This'd be handy for the registration side of two factor authentication etc. You already have the ability to disable voice calls, disable incoming text, etc. so it'd be natural to use Ting as a SMS gateway.
If the concern is giving a third party site credentials, have a separate settable "computer access" password for the account. Or, eventually do it with restricted subaccounts defaulting deny everything then opt-in to various permissions configured from the main login.
Hi James,
Competing with Twilio is a bit of a stretch for Ting but it's been brought up (externally and internally) a few times. If we DID do something like that it would probably be more likely that we'd do it through OpenSRS, or "service that lets you sell Internet Services service".
I like the way you think though!
Oh indeed, Twilio has a lot more features. For basic two factor you don't actually need most of them is what I mean, just basic 'send', and forum operators undoubtedly pay for a mobile phone anyway, why not get their money. :)
Have a good day
James
I actually built an entire server with API around Ting and SMS. The phone is running 2 app store apps. One for monitoring an email address for messages to send and the other to hit a url with inbound messages. I built it with load balancing multi phones for large volume if needed and user accounts so different people can hit the API. Last but not least it monitors inbound STOP messages and block the system from ever sending them another message even if the API requests a send.
The API requests are packaged into an email that the app recognizes the format and sends an email to the mail server. The app on the phone then POPs the email and SMSes the message out. Mail server acts as a queue.
I found this thread when I went in search of an API to monitor my child's phone usage and enable/disable features scriptomatically. A big +1 from me, for what it's worth. I would absolutely love the ability to send SMSes through an API. I had been planning to eventually setup a mifi-esque device for internet backup at home, and being able to have said device send off an SMS would add great options.
I think APIs would be great. It'd open you up to the business community more than you could imagine (think a large organization like a university who needs to bill back specific phones to specific internal accounts, etc)
As a software developer, I would love to see an API. A simple RESTful API would be amazing. In regard to making Ting even better for "normal people", most APIs have a trickle down effect. I have seen developers do innovative and creative things the api designer never imagined. For example, I would use the dashboard information to predict when I will use up my budgeted minutes or estimate my bill. I can do these things now; however, without some form of secure authentication (oauth?) it would not be shareable.
Now that the Android app is out and presumably using some kind of API to retrieve data, are there any plans of posting information on this?
An API would be awesome for the software development geek users!
Yes, please! API!
I'd also love an API. My use case is for generating custom breakdowns of usage and allowing my family members to see how much they are costing us based on a custom pricing distribution algorithm (one that's not purely proportional) and I'd also like to make a custom app that could send warnings based on the rate of usage as opposed to the actual amount used. I just need to be able to programmatically obtain usage information.
API! ;)
bump
I know this is an old thread, but maybe there are some updates?
Being a developer and a statistics geek I would also love to see this. Please Ting! My use would be a landing web-page for my family to check statuses / statistics on devices.
Just for what it's worth, I'm someone else who would like an API. In my case, just for hacking around. All I have in mind is fetching current rates and my own usage, just to do some basic analytics for my own benefit.
Like a couple of others in this thread, I'm mainly interested in this point at something read-only, just to avoid having to scrape HTML.
I'd like to see this, too. Ting doesn't have an app for Windows Phone. I'd like to try making one.
Please sign in to leave a comment.