Real-Time APIs at API Strategies & Practices

Real-Time APIs are much more prevalent than you would probably believe. Some of the best known API providers – whether an API is what they’re known for or not – offer some kind of Real-Time API. WebHooks, HTTP Long-Polling, HTTP Streaming, WebSocket or WebRTC, you’ll be able to find a well-known name that uses one of these as part of their API offering.


API consumers are becoming much more aware of the benefits of real-time thanks to the experiences real-time technology can deliver and the emergence of more real-time APIs. API providers are also beginning to better understand those benefits and in some cases react to the increased demand.

This raises the questions: How do I build a real-time API? and Where do I start when building a Real-Time API?

These are difficult questions that needs to take in many factors. But they’re questions to which I want to shed some light on the answers to in my upcoming talk at API Strategies & Practices Europe/API Day Berlin on Friday the 24th April 2015.

Without going into all the details, here’s what I’m going to cover:

  1. Why you should offer a real-time API and who’s already doing so.
  2. What data should you share and what format should it be in?
  3. What real-time transport should you use?
  4. What Tools can help? Does anything like RAML, Swagger or API Blueprint existing for real-time APIs?
  5. Are there any real-time frameworks that help build an API?
  6. How do you secure your real-time API?
  7. How do you scale your real-time API?

If you’re already booked up for APIStrat/API Days in Berlin then I’ll hopefully see you in the Architecture, Scalability, and Microservices session where I’ll be giving this talk.

If you’ve not yet signed up there’s still time! You can even sign up with a 30% discount thanks to Pusher. This code runs out in a couple of days so register quickly to take advantage.

Ready to begin?

Start building your realtime experience today.

From in-app chat to realtime graphs and location tracking, you can rely on Pusher to scale to million of users and trillions of messages