by Charlie Killian on September 28, 2010, under API, Development, Features
If you have been following the Castfire status blog then you have recently seen several updates involving backend changes for the Castfire API. I want to share with you how those changes will manifest for Castfire clients.
There are six upcoming API key enhancements that fall into two general categories.
API key management
API keys will be decoupled from a user login allowing for a network to create unlimited API keys. Separate API keys can be created and assigned to a specific task or third-party. For example, if you are working with a digital agency like Digitaria, an API key can be created and shared with just them.
The API key can also be given a name, such as “Digitaria” and if needed the API secret can be changed or the API key can be deleted easily in the Castfire CMS.
API key access restrictions
Keeping third-party integrations in mind, API keys can be restricted to one or more API methods. For example, if Digitaria only needs details about existing shows, the API key can be limited to the shows.getDetail API method. If later on, the ability to set show tags is required then access to shows.setTags can easily be added in the Castfire CMS.
Restrictions also encompass content producers, allowing for API keys to be restricted to one or more. For example, if Digitaria wants the ability to set foreign keys on all shows in the “News” content producer, an API key can be created that only has access to this content producer and the only the shows.setDetail API method
These upcoming API key enhancements will make API key management easier, give control over access restrictions and allow for more flexibility when integrating Castfire with third-party vendors.
by Brian Walsh on April 23, 2010, under API, Development, Features
API integrations are a major focus for Castfire, with many of our clients never logging into the CMS to manage their solutions. Our REST based API allows for full control of the platform from website CMS’s, digital asset managers or backend systems. This follows with our philosophy of handling all of the details around publishing audio and video allowing you, the publisher, to focus on content and audience. The API currently has 37 different methods to have complete control over your publishing solution. To make the process of integration even easier, we are releasing foreign key functionality.
If you are a developer, you can skip directly to our API docs.
If you are not a developer, here is a non-technical description:
You have two books in your library and you have numbered them:
You always know that book #1 is Harry Potter and the Philosopher’s Stone and #2 is Harry Potter and the Chamber of Secrets. These, in essence, are your primary keys. They are unique to both books in your library.
Now, you loan your books to your friend, Tom, who has a library of 1,000 books. He also numbers his books from 1 to 1,000. However, books #1 and #2 are:
If you were to speak with Tom about book #1 (his primary key), he would think you are speaking about The Tower Treasure and not Harry Potter and the Philosopher’s Stone – quite confusing. You would have to remember when speaking to Tom, your books are #1001 and #1002 in his library.
To you, #1 is your primary key and #1001 is your foreign key. To Tom, #1001 is his primary key and #1 is his foreign key. It gets hard to manage!
What if Tom always knew, when speaking with you, that your book #1 is actually his book #1001? And your book #2 is actually his book #1002? It would make life a lot easier as you don’t have to keep track of his keys.
That is – in very basic terms – what we have released in our API. Instead of using our show_id (our primary key) when talking to Castfire via the API, you can use your primary key to reference the show. It makes integrations with 3rd party content management and digital asset managements systems even easier. There are less keys to be stored in your system.
I am impressed if you have made it this far! This may sound esoteric, however, it lowers the burden of system integration a great bit allowing for faster implementations. If you have questions regarding our API, feel free to contact support (support@castfire.com, web).
by Brian Walsh on June 10, 2009, under API, Clients, Development, Features, Uncategorized
Two subsystems within Castfire that rarely see the light of the day but power some of the amazing solutions for our clients are the feeds and api. Together, they power syndication, distribution, players and integrations. While they can be considered the same in nature, there are some distinct differences.
Feeds
The approach for feeds is to return structured data in a variety of formats. The most popular formats are supported (xspf, rss, mrss) and publicly available. As much as mrss is trying to be a standard, there are unfortunately many “flavors” available, from Truveo to Bebo to VodPod to – too many to list. All of the different “flavors” are available in our mrss feeds. The feeds are not only for your content as a whole or through a hierarchy – channels and content producers – but can also segment by categories, tags and syndication partners.
A fantastic example of this in action on each of the player biography pages Washington Redskins site (example). The flash player is passed a feed with the latest 10 videos tagged with that players name – a process their staff does religiously with each video. It provides a simple solution, to both code and manage, to place relevant videos into a website.
API
We often refer to our API as the leading indicator of traffic for the coming months, as new clients, integrations and solutions will often develop on the API prior to launching. To date, approximately 90% of the functionality available in our CMS is available through the API. Because of this, many of our solutions are built with deep integrations that do not require logging into the Castfire CMS.
From September, 2008 – May, 2009, we have seen a 2193% increase of usage across both the feeds and API. To put that into perspective, the full month of September’s usage was done in just over 32 hours in May! The new solutions currently being developed are all extremely dependent on both the API and feeds, creating immersive experiences for the audience and streamlined workflows for the publishers. We believe that this is key for our clients success.
If you are interested in learning more about our feeds and API’s, let us know.
by Brian Walsh on December 5, 2007, under API, Development, Features
A lot of time and effort go into both developing and using API’s. Their strengths are documented throughout many products on the web. For me personally, Twitter and Flickr have been models of API’s that change the way I created applications. Looking at an API makes my imagination wander, my drive to tinker and create go wild.
However, API’s also require a certain level of aptitude. The user must understand the basics of programming, know what data to capture, what data to store, etc. In the end, an API may be used by millions but only understood by a small percentage of that. There is, however, an API that we all know how to use: email.
[Side note: my fiancee pointed out to me the other day that I usually spell it "e-mail" with the hyphen. That's the way it was originally spelled. She said I was showing my age!]
When we created our ftp functionality, we wanted to incorporate an easy method for publishers to be able to use the URL’s and embed statements in their websites without having to log back into Castfire. To accomplish this, after ftp’ing files to Castfire, two e-mails are sent:
The email is also "smart" because the directory structure of the publisher’s ftp site mirrors the hierarchy of their account. So a network login sees directories for each content producer and channel, as well as directories for each media type (intro, outro, promo). Each content producer login sees a subset of the network. So a publisher can upload new episodes into the correct channel without having to log in to Castfire – including shows that have multiple content segments.
In addition, default settings, including filenames, metadata, and status can be set for each channel. This is a huge time savings for the publisher as you can set it once and rarely have to revisit it.
We view these e-mails emails as the most basic API possible! FTP and email have been around just about as long as the internet and are accessible to a great majority of web users. While it is possible to log in and publish shows through our CMS, it is many times faster and easier to ftp 10 new videos and get an email back when they are complete.