|No Account (Public)||Free Account||Premium Account (coming soon)|
|Get first page with latest 10 crises (JSON)|| (limited to 10 crises)|
|Get current 10 crises entries as RSS 2.0 Feed|| (limited to 10 crises)|
|Get all entries with 10 entries per page (JSON or RDF/XML) |
API v1 Policy
|Requests per hour||120 requests per hour|
|Requests per day||1440 requests per day|
|Request interval in seconds||One request each 1.0 seconds|
|Access to historic crises information.|
|Advanced statistic information about crises and related resources.|
|More features for premium users coming soon...|
This limits are courtesy limits. That means they are in place in order to prevent buggy or badly written software from taking away resources that could be used by other users. It should remind you to write optimized software that respects best-practise and limited resources on the server-, but also on the client-side.
One good starting point is to ask you if you need all API calls or
if you can prevent a few of them by caching the received results.
For example it is not necessary to query each second if there are
new crises. Currently we receive new crises each 5 minutes.
Make use of existing mechanism to minimize calls, e.g. subscriptions and push notifications. We are working constantly to provide such services and minimize the effort for your application. Manual calls cost not only network traffic, but also CPU and memory. This is especially important if you develop a mobile app.
Please contact our support under .
The REST API and the website share the session cookies. That keeps the server stateless, but allows the user to omit the auth_token during testing. Additional the session sharing is the base for the OAuth2 authentication workflow.