ver. 1382 (3aeabce)

The OKAPI Project
:: Opencaching API Reference

OKAPI is a publically available API for "National Opencaching" sites.

  • 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 Authentication.

The project has grown to become a standard and common API for all National Opencaching.xx sites. This OKAPI installation provides services for the site. Here is the list of other OKAPI installations:

Other links you might want to check out:

* - Opencaching.DE includes other sites - Opencaching.IT, OpencachingSpain.ES and Opencaching.FR - which are in fact the one site visible on multiple domains. All three share one database, so you can access all their data through Opencaching.DE OKAPI installation.

How can I use OKAPI?

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

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

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

You've just made your first OKAPI request! This method was a simple one though. 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.

"Minimum" 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).

Most methods can be called with "Level 1" authentication, so for most applications you won't have learn OAuth.

  • Level 0. Anonymous. You may call such methods with no extra authentication-related 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). For most languages there are some OAuth 1.0a libraries which can do this for you.


  • 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). For most languages there are some OAuth 1.0a libraries which can do this for you.



Whichever you want. OKAPI will treat GET and POST requests equally. You may also use the HTTP Authorization header for passing OAuth arguments. OKAPI does not support other HTTP request types (such as PUT or DELETE).

A warning about HTML fields

Many of the fields returned in OKAPI responses are formatted in HTML. However, most of these fields come directly from the underlying Opencaching database. Currently, these fields are not validated by OKAPI. They should be validated by the Opencaching site itself (prior to inserting it to the database), but we cannot guarantee that they will be. And you shouldn't count on it too.

You must assume that our HTML content may contain anything, including invalid HTML markup, tracking images (pixels), or even XSS vectors. This also applies to the descriptions included in the GPX files.

Common formatting parameters

Most of the methods return simple objects, such as lists and dictionaries of strings and integers. We may format such objects for you in several ways. If you want to change the default (JSON) then you should include common formatting parameters in your request:

  • 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),

    • jsonp - JSONP format (if you choose this one then you have to specify the callback parameter too),
    • xmlmap - deprecated (why?),
    • xmlmap2 - XML format. This is produced by mapping JSON data types to XML elements.
  • callback - (when using JSONP output format) name of the JavaScript function to be executed with the result as its parameter.

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

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!

OAuth Dance URLs

If you want to use Level 3 methods, you will first have to perform "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 on, you'll probably want to replace "oob" with something more useful (your own callback).

  • 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. The 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. The body will contain a JSON object describing the error (see 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. Usually you should treat such errors as other I/O errors (e.g. display a "No connection, try later" notice). We will try to fix such errors as soon as possible.
  • Sometimes, due to invalid server configuration, you may receive HTTP 200 instead of HTTP 500. We know that's "unprofessional", but we cannot guarantee that all OC servers are configured properly (example). If you get HTTP 200 and you cannot parse the server response, you should treat it as HTTP 500.

Every HTTP 4xx error will contain an additional description in the response body. This description will be always formatted in JSON (regardless of the format parameter you might have used in your request). You can use this information to pinpoint the source of the error.

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 - a list of keywords which depicts the exception's position in our exception class hierarchy (see below for valid values),
  • status - HTTP status code (the same which you'll get in response HTTP header),
  • 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. Currently possible values of the reason_stack include:

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


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

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

      • parameter - the name of the parameter,
      • whats_wrong_about_it - a string, pretty self-explanatory,
  • ["invalid_oauth_request"] - you've tried to use OAuth, but your request was invalid.


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

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

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

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

    • [ "invalid_oauth_request", "invalid_token"] - your token does not exist. This error is pretty common! Your token 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_oauth_request", "invalid_signature"] - your request signature was invalid.

    • [ "invalid_oauth_request", "invalid_timestamp"] - you used a timestamp which was too far off, compared to the current server time. This error is pretty common, especially if your app is for mobile phones! You may ask your user to fix his clock, or you could use the provided extra keys to adjust your oauth_timestamp parameter yourself. Extra keys:

      • yours - UNIX timestamp you have supplied (this used to be a string, but now it is being casted to an integer, see here),
      • ours - UNIX timestamp on our server,
      • difference - the difference, in seconds (to be added to your clock),
      • threshold - the maximum allowed difference.
    • [ "invalid_oauth_request", "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.

In most cases, you should be fine with catching just the following (order significant):

  • ["invalid_oauth_request", "invalid_token"] (reauthorize),
  • ["invalid_oauth_request", "invalid_timestamp"] (adjust the timestamp),
  • any other 4xx status exception (send yourself a bug report).
  • All other errors - including HTTP 5xx responses, JSON parsing errors, timeouts etc. - should be treated as connection errors (ask the user to try later).

Important backward compatibility note: If Z is a subclass of X, then it will forever stay a subclass of X. However, class X won't necessarilly stay Z's direct parent. This means that ["x", "z"] may become ["x", "y", "z"] or even ["w", "x", "y", "z"] one day. In other words, instead writing if (reason_stack == ["x", "z"]) { ... } you should rather use if ("z" in reason_stack) { ... }.

Differences between OCPL and OCDE branches

Client developers should be aware that the are two primary Opencaching codebase branches. Some Opencaching installations are running the OCPL branch, some other are running the OCDE branch. (You can read more about this here.)

In general, OKAPI supports both of these branches via exactly the same API interface, so you don't have to worry about the internal differences. However, you should be aware of the fact, that some things work a bit different on one branch, than they on the other. (Like, for example, OCDE doesn't have a cache rating system, so whenever you ask for the rating field of a geocache, you will get null.)

In order for you to easily notice methods, parameters and fields which are specific to only a single of these branches, we display the following "tags" in many places:

  • OCPL - indicates that a certain method, parameter or field was designed specificly for OCPL-based Opencaching sites,
  • OCDE - indicates that a certain method, parameter or field was designed specificly for OCDE-based Opencaching sites.

Please note, that you still MAY use all such "marked" methods, parameters and fields on ALL OKAPI sites. Our methods are designed in such a way that, even if they are not supported by the underlying Opencaching site, they still won't throw errors, etc. At worst, they will "fail silently", or return empty results. All these differences should be described in detail in the documentation of the affected methods, parameters and fields.

If you have any questions about this, then ask them here.

How can I participate in OKAPI development?

OKAPI is Open Source and everyone is welcome to participate in the development.

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: