Latest documentation

The latest documentation for using the service

The complete software stack as well as the install instruction and documentation
of the ePIC API V2 can be found under

Older documentation

Specification of the ePIC-API version 2.0 (from Februar 2012, deprecated):

API v2 suffix structure (for prefixes 11022, 11372, 11148, 11378)

As an example of such a structure we describe in the following the suffix structure for prefix 11022

Since persistent identifiers should carry as less semantical content as possible it was decided that the structure of the handle itseld should be rather flat.

There are only two possible optional fields, prepending and appending the generic suffix field, that can be used by the customers for there own purposes, but it is strongly recommended to use this only in very rare cases, since this can bring too much semantic into the handle, that can disable its timeless relevance.

The generic suffix field of an ordinary handle contains a body of numbers together with a checksum to ensure plausibility of the handle string. All entries of these fields are uppercase alphanumerical or hexadecimal digits.
The concrete structure of the issued handles are of the following forms:

the ordinary handle has the form



the optionally augmented handle (not recommended, see above) has an optional prepending and/or appending field, that can be used independently from each other



the meaning of these fields above is:

prfix is the handle prefix, which is in this case to 11022

num1-num2-num3 are 12 bytes, coded in uppercase hexadecimal digits with delimiters

c is a checksum to ensure plausibility of the handle string.

OPTIONAL_PRE and OPTIONAL_APP are optional fields maximal 32 letter for uppercase alphanumeric characters that can be used by the institutes for there own purposes.

Resolution of Handles
In general handles can be resolved by the handle proxy

One gets back the refered digital object by appending the handle profix and suffix to the handle proxy address like Such a request is first sent to the Handle System’s Global Handle Registry (GHR). The GHR responds by sending the client the location information for the relevant Local Handle Service (which may consist of multiple servers in multiple sites); a query is then sent to the relevant server within the Local Handle Service. The Local Handle Service returns the information needed to acquire the resource, e.g., a URL which can then be turned into an HTTP re-direct. If the client already has information on the appropriate LHS to query, the initial query to GHR can be omitted. One of ePIC goals is to provide a network of replicated Local Handle Services, such that the overall structure ensures a highly available resolution service for the PIDs, that are supported by the ePIC partners.