The Zen of Camera to Cloud

The Guiding Principles of Camera to Cloud

What is the Camera to Cloud API?

The Camera to Cloud (C2C) API offers a way to send media directly into the moment recording stops with no additional input from the user of your device, while maintaining strong security guarantees. It is our vision at that the moment a user stops recording — or makes a metadata entry — their media is available for them in to review and collaborate.

When we sat down to make this vision a reality, it became clear that to offer the best experience for both integrators and users, we needed to make the C2C API it's own mini "backend", distinct from the rest of's ecosystem. This might not seem like an obvious choice at first glance, why not just use the existing API?

In this article we will lay out the specific goals and philosophy of C2C by exploring its guiding principles.

Bytes to Cloud

First, let's dispel a false impression. Camera to Cloud was named with the Rule of Cool — it's alliterative, evocative, and looks great on swag. But it's also a bit of a misnomer. Does your device and / or App create bits? Do you want those bits in as soon as possible? Is that all you really need your device and / or App to do?

Camera to Cloud might be right for you!

We don't really care what the bits are. Sound, Video, PDFs — will accept any file type. We thought Visual Audio And Other Media Plus Supporintg Documents To Cloud sounded better, but we got overruled by Marketing. For some reason.

Write, but don't read takes its security guarantees very seriously, and allowing devices to communicate affords a new vector for bad actors. Many cameras, sound recorders, and other physical media devices don't have passwords, screen locks, and other security features because they are not traditionally connected to the web. If we were to give access to the full API to these devices, they could become possible security breaches if left unattended.

Additionally, the person operating the device might not even be someone who should be given access to the greater project. Their job might simply be to create some of the media, not manage all of it.

That lead us to a broader point: Cameras exist to create media, not review or comment on other devices' media, so the way to solve a potential security problem is to make an API that is bounded purely to the problem we are trying to solve anyway: writing data to the cloud. The best way to stop bad actors from reading data they shouldn't? Don't make it possible to read that data in the first place.

Where we're going, we don't have GUIs's existing APIs make an assumption: you are writing an App. That App wants to talk to That app has a GUI, just like our app. We assume we can send you a list of things, you can display that list to the user, and the user can decide to take some action on that list which in turn is communicated back to the server.

But with devices, now our "app" is not really an App at all. It's a physical device which may or may not even have a GUI. Which may or may not support user input at all.

When designing C2C, we had to ask ourselves: could we integrate this API on a pager? Unfortunately, React.js has yet to release support for pagers, so a much simpler way of interacting with the user had to be targeted. A way that did not require the user to make any sort of input on the device, since in many cases they might not be able to.

That ruled out the existing API on another front: We can't redirect to a webpage to sign in, can't count on the user being able to enter a username / password. Can't count on the user being able to select a folder to drop their footage into. We didn't need to just pair down what actions a device could take, but the entire experience around accomplishing those actions.

We also kinda don't have internet?

Not only do our devices not have necessarily have a traditional GUI, they also might not have access to consistent internet. So we needed to design our API in a way to not require tons of communication to the backend — to keep the number of calls required during operation to an absolute minimum so that camera operators on remote sets with spotty WiFi or Cellular service could still have a good experience.

Make integration simple

Lastly, we needed to make integration as simple as possible. A handful of endpoints, minimal requirements for back-and-forth negotiating with the server, and a small surface area laser-focused on what it is we actually want to accomplish. We recognize that this might be the first set of third-party network calls some of our integrators are writing! Whether you are experienced with REST API's and just want to get through integration as fast as possible, or this is your first time writing an HTTP call, we want your experience to be as smooth and painless as possible.

Next up

If you haven’t already, we encourage you to reach out to our team, then continue to the next guide. We look forward to hearing from you!