- February 21, 2012
- 75
- 22
- 58
- Home Country
- United Kingdom
Well it seems the party is well & truly over.
changes to atlas access
Today we're announcing some changes to the way we make data available for smaller users ofAtlas.
xmltv feed
Back in December 2011, MetaBroadcast took over from RadioTimes the job of supplying UK linear TV schedule data to the XMLTV community. Until this point, RadioTimes had provided a feed, which was turned off as part of a systems change. While we initially provided a like for like replacement, the original announcement made clear that we would move users to a different service in due course.
We stopped maintaining this feed back in 2012, and announced it would eventually be discontinued. Today we are confirming that this feed will be turned off on 16 June 2016.
atlas api
For many years we have offered access to data via Atlas for a wide range of users, beyond our usual customer base of large media companies, including a limited free trial. We do this because we believe everyone should have the chance to get a new service off the ground. Several of our customers started on a free trial, and went on to build impressive TV services.
In early 2014 we made it possible to sign up for an API key via the Atlas website, on a self serve basis. At this point we introduced clear terms for how the API was made available, which have remained unchanged until today. The terms are availablehere. Some of the key terms are:
❝Use what you need, and no more. Atlas serves end-users, not servers. Request the data your users need, direct from their client, and when they need it.❝Don't cache Atlas data on a server or cache or CDN or API gateway, or similar, between us and your client. Our data gets updated frequently, so it's inefficient for everyone if you store it, then have to keep polling for updates.❝Don't pre-request lots of data when your app, or a part of your app loads. Atlas is fast enough to serve your users when they request stuff, so pre-requesting data just wastes resource and makes things slow.
It has recently become clear that some users are not following these terms, and that some of the API calls made by these users are extremely resource-intensive to serve. In particular, some users have been requesting up to 14 days of data in a single call. This is clearly far more than is required to serve any immediate user need.
Today we are asking that all users of Atlas sign in, reconfirm their acceptance of the terms, and provide information about the application they are using Atlas for. We have published a separate blog postherethat describes how to do this.
We are also today making the first changes to the Atlas terms in two years, including changes to the clause around when we provide free access. This now reads:
❝Atlas access is provided initially free of charge on a trial basis for up to ten users, so that we can support early development of apps. Beyond 10 users on a single API key, or for trials continuing longer than three months, a charge is levied based on the number of users you have, and the features you use.
Those with an API key have today received an email asking them to log into the Atlas website, reconfirm their compliance with our terms and conditions, and provide further details about their application, so that we can assess whether to provide a time-limited free trial. These actions should be completed by 6 June for the key to stay active. Unfortunately, the keys of those users not completing these actions will be revoked on 6 June 2016.
We have also written specifically to users making resource-intensive calls to Atlas, asking that they change their usage. We may make further such requests by email to the address with which you registered your key, and will give a time limit for changes to be made for your key to not be revoked. This will often be quite tight. Additionally, it's now necessary to revoke any key making requests for more than 24 hours of data in a single call, without further warning.
other sources of TV listings data
We understand these arrangements will not suit everyone, especially those users who are running software for personal use, who will want to maintain access permanently without paying for using Atlas. If you fall into this category, we recommend you consider some of the other options to obtain data. For example, we are aware of a US-based non-profit organization calledSchedules Directthat offers schedule data for personal use, charging a small annual fee. We have not been in contact with this organisation, so cannot specifically recommend them, however they do appear to offer the service that some current Atlas users require.
anything else?
If you do need to contact us about this, you can use the contact formhere. We will not be monitoring messages via other channels. Please note you will need to log in to use the form, and to use a supported browser such as Google Chrome. Unfortunately we won't be able to answer all messages individually.
in summary
The key points in this post are:
If you enjoyed the read, drop us a comment below or share the article, follow us onTwitteror subscribe to our#MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it's time we worked together.
- The former RadioTimes XMLTV feed will stop on 16 June 2016.
- We have updated our terms for the first time in two years, including clarifying when free access to Atlas is provided.
- All users of Atlas APIs must log in and reconfirm compliance with terms and conditions by 16 June 2016, following the instructionshere. Applications that do not confirm by 16 June 2016 will have their API keys revoked.
- In addition, we will advise some applications of changes in their API calls that are required.
- One specific change required is that no call to the Atlas schedule endpoint should request more than 24 hours of data. Applications not following this rule will be revoked without further notice.
- Those making personal use of Atlas may well want to consider another source of data, such asSchedules Direct.
- You can contact MetaBroadcast via the contact formhere, although we cannot commit to answering all messages individually.