Today is a milestone for Burner: we are releasing a first-class API.
From our earliest days starting this company, we’ve been consumed with how much better a person’s phone number can be when it can be treated like software.
Email is a useful analog. Over the last two decades, we’ve seen email evolve from being a static, ISP-controlled phenomenon in the AOL era, to being free and ubiquitous in the Hotmail era, to becoming a platform with the emergence of Gmail. Along with this came better and better user-facing features, beginning with things like tagging, search, and spam protection, and further evolving with recent capabilities like machine-learning-based inbox prioritization and automated response suggestions powered by artificial intelligence. In parallel, the gmail platform was opened to third parties at both the UI level and the data level, leading to a whole ecosystem of integrated apps, third-party providers, and the ability to drive entire applications from within the Gmail UI.
Given the way people use messaging as a primary way of communicating today, shouldn’t text messages get all the bells and whistles that your email has? We’ve always thought so.
Burner does this in a bunch of ways in the app itself, but the idea of opening it up and connecting the phone number to other smart pieces of software has always been particularly exciting to us.
We called Connections a “non-obvious no-brainer” when we launched it as a platform and with our first few integrations. We didn’t initially know where it would take us, but connections that pipe Burner messages, media, and contacts into apps like Slack and Google Sheets, and agents like Ghostbot that run inside your Burner phone number, have proved out our belief that incredible user utility and value that comes from “un-siloing” the phone & messaging app. They’ve also hardened our conviction that all phone numbers will have these kinds of connections and programmatic capabilities in the near future.
Today’s release builds on this idea with a first-class API offering programmatic access to Burner’s user- and line-level features, supported by OAuth 2.0. Key Burner features include per-line configuration and settings, contact management, blocking and muting, content filtering, text auto-responses, and more.
The API, which we’ve been dogfooding for a bit, builds on the webhook system we previously had available for listening to and sending messages, by enabling access to the “higher” Burner functions like per-line identity and configuration settings, contact management, blocking and muting, content filtering, text auto-responses, and more. (Webhooks remain available and can be used in combination with the API and set via the API.)
With this API, a developer can do things like:
- change a user phone line’s ringer and notifications settings based on external events or conditions, or vice versa
- listen to incoming messages, read and process their content, and respond as a bot/agent or trigger other events based on context
- sync contacts between a Burner account and other services
- automatically text others from a user’s phone based on external triggers and data
- integrate and optimize phone numbers for use with another service, which can add phone number info to an external profile, update contacts and so on
So it’s the best of both worlds in the sense that a developer gets access both to network-level controls (comparable to a basic telephony API) and to application-level features associated with a robust consumer messaging client. OAuth can also be used to enable users to also verify their Burner identity in a secure and psuedonymous way anywhere on the web, and it can be used to support platform integrations like our upgraded Zapier channel.
This of course is a first API release, and there’s much more to do looking forward. But we’re excited to put this in the world along with Hostbot, an app for Airbnb and similar hosts that showcases it, and to see where this takes us next.
