rev. 901

The OKAPI Project
:: Opencaching API Reference

OKAPI is a public API project for National Opencaching sites (also known as Opencaching Nodes).

  • It provides OC site with a set of useful well-documented API methods,
  • Allows external developers to easily read public Opencaching data,
  • Allows read and write private (user-related) data with OAuth 3-legged authentication.

The project is aiming to become a standard API for all National Opencaching.xx sites. This OKAPI installation provides API for the site. Check out other OKAPI installations:

Opencaching.DE includes the sites Opencaching.IT and OpencachingSpain.ES, which are "national views" of Opencaching.DE. All three share one database, so you can access all their data through the Opencaching.DE OKAPI installation and select Italian or Spanish language.

And also:

How can I use OKAPI?

We assume that you're a software developer and you know the basics.

OKAPI is a set of simple (REST) web services. Basicly, you make a proper HTTP request, and you receive a JSON-formatted data, that you may parse and use within your own application.

Example. Click the following link to run a method that prints out the list of all available methods:

You've made your first OKAPI request! This method was a simple one. It didn't require any arguments and it didn't require you to use a Consumer Key. Other methods are more complex and require you to use your own API key.

Authentication Levels

Each OKAPI method has a minimum authentication level.

This means, that if you want to call a method which requires "Level 1" authentication, you have to use "Level 1" authentication or higher ("Level 2" or "Level 3" will also work).

Important: Most developers will only need to use "Level 1" authentication and don't have to care about OAuth.

  • Level 0. Anonymous. You may call this method with no extra arguments.


  • Level 1. Simple Consumer Authentication. You must call this method with consumer_key argument and provide the key which has been generated for your application on the Sign up page.


  • Level 2. OAuth Consumer Signature. You must call this method with proper OAuth Consumer signature (based on your Consumer Secret).


  • Level 3. OAuth Consumer+Token Signature. You must call this method with proper OAuth Consumer+Token signature (based on both Consumer Secret and Token Secret).



Whichever you want. OKAPI will treat GET and POST requests as equal. You may also use the HTTP Authorization header for passing OAuth arguments. OKAPI does not allow usage of PUT and DELETE requests.

Common formatting parameters

Most of the methods return simple objects, such as lists and dictionaries of strings and integers. Such objects can be formatted in several ways using common formatting parameters (supplied by you along all the other parameters required for the method to run):

  • format - name of the format in which you'd like your result to be returned in. Currently supported output formats include:

    • json - JSON format (default),

      Use Chrome or Firefox extensions to view JSON results directly in your browser. This simplifies debugging a lot!

    • jsonp - JSONP format, if you choose this one, you have to specify the callback parameter,
    • xmlmap - deprecated (why?),
    • xmlmap2 - XML format. This is produced by mapping JSON data types to XML elements. Keep in mind, that XML format is larger than JSON and it takes more time to generate and parse. Try to use JSON when it's possible.
  • callback - (when using JSONP output format) name of the JavaScript function to be executed with the result as its parameter.

Important: Almost all of the returned data types are extendible. This means, that (in future) they may contain data that currently they don't. Such data will be included in backward-compatible manner, but still you should remember about it in some cases (i.e. when iterating over attributes of an object). This additional data may appear as extra elements in GPX files or extra keys in JSON responses. Your software must ignore such occurrences if it doesn't understand them!

Some methods expose some special formatting of their own, for example, they may return a JPEG or a GPX file. Such methods do not accept common formatting parameters.

OAuth Dance URLs

If you want to use Level 3 methods, you will have to make "the OAuth dance" (series of method calls and redirects which provide you with an Access Token).

The three OAuth request URLs defined in the OAuth specification are:

Things you should pay attention to:

  • The oauth_callback argument of the request_token method is required.

    As the OAuth 1.0a specification states, it should be set to "oob" or a callback URL (this usually starts with http:// or https://, but you can use any other myapp:// scheme).

    For most OAuth client libraries, you just should provide "" as the request_token URL, to get it started. Later, probably you'd want to switch "oob" to something more useful.

  • The oauth_verifier argument of the access_token method is also required.

    When user authorizes your application, he will receive a PIN code (OAuth verifier). You have to use this code to receive your Access Token.

  • Access Tokens do not expire (but can be revoked). This means, that once the user authorizes your application, you receive a "lifetime access" to his/her account. User may still revoke access to his account from your application - when this happens, you will have to redo the authorization dance.

Advanced error handling

Basic rules apply:

  • If all goes well, OKAPI will respond with a HTTP 200 status.
  • If there is something wrong with your request, you will get a HTTP 4xx response (with a JSON object described below). These kind of responses should trigger some kind of an exception inside your application.
  • If something goes wrong on our part, you will get a HTTP 5xx response. We will try to fix such errors as soon as possible.

Each HTTP 4xx error will be properly described in the response, using a JSON error response. You may retrieve the body of such response and use it inside your application (for example, to construct various exception subclasses). In most of the cases, only OAuth applications need to do this. All other applications are fine with threating all HTTP 4xx errors the same.

The error response is a dictionary with a single error key. Its value contains at least the following keys:

  • developer_message - description of the error,
  • reason_stack - list of keywords (see below for valid values) which may be use to subclass exceptions,
  • status - HTTP status code (the same which you'll get in response headers),
  • more_info - url pointing to a more detailed description of the error (or, more probably, to the page you're now reading).

Depending on the values on the reason_stack, the error dictionary may contain additional keys. Possible values of the reason_stack include:

  • ["bad_request"] - you've made a bad request.


    • [ ... , "missing_parameter"] - you didn't supply a required parameter. Extra keys:

      • parameter - the name of the missing parameter.
    • [ ... , "invalid_parameter"] - one of your parameters has invalid value. Extra keys:

      • parameter - the name of the parameter,
      • whats_wrong_about_it - description of what was wrong about it.
  • ["invalid_oauth_request"] - you've tried to use OAuth, but your request was invalid.


    • [ ... , "unsupported_oauth_version"] - you tried to use unsupported OAuth version (OKAPI requires OAuth 1.0a).

    • [ ... , "missing_parameter"] - you didn't supply a required parameter. Extra keys:

      • parameter - the name of the missing parameter.
    • [ ... , "unsupported_signature_method"] - you tried to use an unsupported OAuth signature method (OKAPI requires HMAC-SHA1).

    • [ ... , "invalid_consumer"] - your consumer does not exist.

    • [ ... , "invalid_token"] - your token does not exist. This is pretty common, it may have expired (in case of request tokens) or may have been revoked (in case of access tokens). You should ask your user to redo the authorization dance.

    • [ ... , "invalid_signature"] - your request signature was invalid.

    • [ ... , "invalid_timestamp"] - you used a timestamp which was too far off, compared to the current server time. This is pretty common, especially when your app is for mobile phones. You should ask your user to fix the clock or use the provided extra keys to adjust it yourself. Extra keys:

      • yours - timestamp you have supplied,
      • ours - timestamp on our server,
      • difference - the difference (to be added to your clock),
      • threshold - the maximum allowed difference.
    • [ ... , "nonce_already_used"] - most probably, you have supplied the same request twice (user double-clicked something?). Or, you have some error in the nonce generator in your OAuth client.

Almost always, you should be fine with catching just three of those:

  • ["invalid_oauth_request", "invalid_token"] (reauthorize),
  • ["invalid_oauth_request", "invalid_timestamp"] (adjust the timestamp),
  • and "any other 4xx status exception" (send yourself a bug report).

How can I participate in OKAPI development?

OKAPI is Open Source and everyone is welcome to participate in the development. In fact, if you'd like a particular method to exist, we encourage you to submit your patches.

We have our Issue tracker. You can use it to contact us!
You may also contact some of the developers directly, if you want.

Visit project homepage for details:

List of available methods

OKAPI web services (methods) currently available on this server: