The Search API provides a way to search for metadata records and media on the Europeana repository, for instance give me all results for the word "Vermeer". Besides the ability to directly search on Europeana, this API also provides an auxiliar method for translating queries and support for the OpenSearch.RSS protocol.

The Search API is the easiest API to use and understand. It interacts with Europeana's data in much the same way as the Europeana Collections does. You can search for keywords, and the API will return all records that match that keyword. You can refine your search with more advanced queries like Boolean Searches, or you can filter out parts of the results advanced filtering. You can choose to only return objects which have certain copyright statements, and you can choose to return the results in a language of your choice. This means that with the search API, you can get a response to the query: 'Give me all objects by Vermeer that are openly licensed and have big images.'

If you wish to perform more advanced queries that need to delve into the structured metadata of Europeana (for instance, to ask the question What are all the French 18th-century painters with at least five artworks available through Europeana) then using the SPARQL API is a better choice.

Before start using this API, we recommend reading the introduction page for an overview of the EDM model, registering for an API key, and reading the Terms of Use. If you want to get started with this API, go directly to the Getting Started section or try it out directly on the Console.

Deprecation Information

The following will be deprecated per the given date, ensure that your API clients are updated accordingly:

Roadmap and Changelog

We deploy new versions of the portal and API quite regularly, but not all new versions result in changes in the interface. The current version of the Search API is 2.9.0 (2019-07-15). To see the changes made for this version and also all previous releases, see the API changelog in the project GitHub.

Backward Compatibility (v1)

The current version of the Europeana API (API2) is fully backwards compatible with the previous version (API1). However, we encourage developers to switch to the new naming of the fields that were used in API v1. For more information on the mapping between the new and the old fields, please see V1 to V2 Compatibility.

Every call to the Search API is an HTTPS request in the following URL signature:

https://api.europeana.eu/record/v2/search.json

Notice: The APIs are now being served under a unified and dedicated address "https://api.europeana.eu/" separate from our Portal. We have done so to better manage the traffic to the APIs besides making it more intuitive for you (our users). We will keep serving under the old https://www.europeana.eu/ while we still see traffic going via this route. We kindly advise you to change your clients to use the new API endpoint.

with the following parameters:

Example: Search for all openly licensed records with a direct link to the full media file:

https://api.europeana.eu/record/v2/search.json?query=Paris&reusability=open&media=true (Try on Console)

Response

A response to the Search API is always formatted in JSON and will contain a number of fields that present information about the handling of the request, while the concrete information about the record is presented in the "items" field (see Metadata Sets).

Error Responses

An error occurring during processing of an API method is reported by (1) a relevant HTTP status code, (2) a value of the success field and (3) a meaningful error message in the error field. The following table shows the fields appearing within an error response:

The following kinds of errors can be returned by the Record API:

Example: Request to the Search API supplying an invalid (unknown) API key

https://api.europeana.eu/record/v2/search.json?query=*&wskey=test

{
    "apikey": "test",
    "success": false,
    "error": "Invalid API key"
}

Search Fields outside EDM

In addition to the fields defined in EDM, a handful of other fields were defined for administrative reasons which can also be used to search.

Language-specific Search Fields

In EDM, most of the properties that accept a Literal may be language tagged, meaning having a language code that determine the language of the text using the ISO 639-2 standard. To allow for a language specific search on such properties, the Search API defines a field for each of the language variations that appear in our repository while keeping the base field with all the values in all language variations. As opposed to the base field which typically has datatype Text (some fields may also be defined as String), the language specific fields are always of type String to allow for faceting with the complete value (with no tokenization), see datatypes for more details. If a language specific field is part of a metadata set, it can also be output in the response.

The following table shows the base and language specific search fields for the dc:creator property:

Search Fields defined in EDM

EDM defines an extensive list of class and properties. In the Search API only a subset of these, corresponding to the ones found to be the most commonly used, can be used to search in the repository. These fields are listed in this section.

The ML (ie. multilingual) column of the table below marks the fields that have multilingual variations.

Notes:

¹ This field has been deprecated with edmDatasetName. This change followed the change in EDM to rename to edm:collectionName to edm:datasetName. We will keep support for edmCollectionName for a grace period, but on January 2018, we will return only edmDatasetName so please update your API client.

Aggregated Fields

Europeana aggregates its data from cultural institutions that can use diverse, fine-grained systems and methodologies. As a result, a link between for example an object and a person may be stored in different specialized fields. To provide simpler views on this data, Europeana has introduced several general Aggregated Fields, such as: title, who, what, when, and where. In these fields, we gather together information from different record fields in order to make the discovery of objects easier. Title, for example, aggregates data from the dc:title and dcterms:alternative fields which are part of Dublin Core, a popular general standard for describing different types of resources.

Media Search

The Search API allows not only to search on and retrieve metadata, but also offers powerful features based on technical metadata. Technical metadata is metadata which is extracted from media files such as images and videos which are associated to records, such as the width and height of an image. These features give you the possibility to search for and filter on Europeana records by media information, for instance to only search for records which have extra large images, high-quality audio files, or which images match a particular colour. Besides searching and filtering, faceting is also possible using technical metadata and, in fact, is part of the default facets provided by the facet profile. These features were developed as part of the Content Re-use Framework within the Europeana Creative project.

A Europeana metadata record can contain a reference to zero, one or more media files, this means that when a search is made on a technical metadata property or facet (such as image size), a record is returned if one of the media files present in the record match the search query. The following table lists the fields that relate to the metadata extracted from the media resources:

Colour palette

From all records with images, the six most prominent colours are extracted. These colours are then mapped to one of the 120 colours that can be found in the listing here. To search for records where one of the images matches a particular colour you can use the colour palette parameter, you can provide it multiple times. You need to provide a Hex rgb code as value, such as #8A2BE2 or #FFE4C4.

Datatypes for Search Fields

The following datatypes are defined for the search fields used for querying, filtering and faceting.

The possible values of the reusability parameter are shown in the following Table:

Example: Search only for freely reusable records:

https://api.europeana.eu/record/v2/search.json?query=Paris&reusability=open (Test on API Console)

A profile typically determines how extensive the response will be, by either dictating the metadata fields that will be present (ie. minimal, standard and rich) or appending additional data elements such as facets or breadcrumbs. Most facets can be combined with the exception of the metadata facets or combined facets such as rich. The following table lists the profiles supported by the API:

Breadcrumbs

A collection of search queries that were applied in this call.

Each item in a search result is represented by a subset of the fields from the corresponding metadata record. The extent of the fields that are present is determined by the Profile chosen.

Result Fields outside EDM

In addition to the fields defined in EDM, a handful of other fields were defined for administrative reasons that are output in the response.

Language-specific Result Fields

The same way as there are separate language specific fields for searching, there is also a way to distinguish language specific values for the response. Such fields always end with the suffix "LangAware" and are represented as LangMap. In order to preserve backwards compatibility we have not changed the original fields. This means that fields such as title, description and creator now appear twice in the search response, one with their original field name (dcTitle) and one as a multilingual labelled list (dcTitleLangAware). In the future we will replace the single-value fields for the correct multilingual ones.

The following table shows the base and language specific result fields for the dc:creator property:

Result Fields

The table below lists all the fields that are output by the search divided per profile (metadata set).

¹ This field has been deprecated with edmDatasetName. This change followed the change in EDM to rename to edm:collectionName to edm:datasetName. We will keep support for edmCollectionName for a grace period, but starting from January 2018, we will return only edmDatasetName so please update your API client.

JSON Datatypes

The JSON output of this API uses the following datatypes:

Example: Include the broadest set of metadata in the search response:

https://api.europeana.eu/record/v2/search.json?query=Paris&profile=rich (try on console)

The number of records that Europeana contains is very big and growing. Therefore we need efficient ways to allow our users to discover what they need easily. One such technique is a faceted indexing system that classifies each record along multiple dimensions. The facets, seen on the left side of the Europeana Collections Portal, can be useful for filtering search results and can also be used by API clients. If you conduct a search for the keyword "paris" and have a look at the TYPE facet, this facet would tell how many items exist within your search result grouped by TYPE (such as IMAGE, VIDEO etc.). All search fields can also be faceted on.

When you search within your result set for a specific facet, the other items in your facet would still exist (if you search for TYPE:IMAGE, then you can still see how many results there are for TYPE:VIDEO etc.). This last functionality, called multi-facets, is not supported for the Technical Metadata fields.

Requesting Facets

Facets can be requested by either setting the facets or the portal profiles with the profile parameter. By default, a predefined set of facets is returned corresponding to the facets seen on the left side of the Europeana Collections Portal, which correspond to the following search fields:

• TYPE, LANGUAGE, COMPLETENESS, CONTRIBUTOR, COUNTRY, DATA_PROVIDER, LANGUAGE, PROVIDER, RIGHTS, UGC, YEAR, COLOURPALETTE, MIME_TYPE, REUSABILITY, IMAGE_SIZE, SOUND_DURATION, VIDEO_DURATION, TEXT_FULLTEXT, LANDINGPAGE, MEDIA, THUMBNAIL, IMAGE_ASPECTRATIO, IMAGE_COLOUR, VIDEO_HD, SOUND_HQ

Facet objects in the Response

When requested, facets appear on the response within the facets field as an Array of Facet objects, which are composed by the following fields:

Example: Requesting default facets for all Europeana records

https://api.europeana.eu/record/v2/search.json?wskey=YOUR_KEY&query=*&rows=0&profile=facets

{
  "apikey": "YOUR_KEY",
  "success": true,
  "requestNumber": 999,
  "totalResults": 53008466,
  "items": [],
  "facets": [
    {
      "name": "RIGHTS",
      "fields": [
        {
          "label": "http://rightsstatements.org/vocab/InC/1.0/",
          "count": 21135772
        },
        ...
        {
          "label": "http://creativecommons.org/licenses/by-nc-nd/3.0/de/",
          "count": 2732
        }
      ]
    }
    ...
  ]
}

Individual Facets

It is also possible to select which facets to retrieve beyond (or instead of) the default facet set, via the facet parameter.

The value of the parameter could be "DEFAULT" (which is a shortcut for the default facet set) or any search field. A remainder that search fields with datatype Text are indexed as tokenized terms which imply that facet values and counts will reflect such terms as opposed to the whole value (ie. phrase) like in the remaining datatypes. This is the reason why the language specific search fields were added with type string so that faceting could be done on the complete values. These are the fields actually used by the Europeana Collections Portal to display the facet values on the left side.

We have aligned the logic for faceting across all fields in the API output to be consistent. Previously, faceting on the 'default' facets (such as TYPE, or RIGHTS) would use a different logic than faceting on custom fields (such as proxy_dc_creator). The difference is that now all other values in a list of facet values are returned (multi-facet).

Example: Requesting an individual facet

https://api.europeana.eu/record/v2/search.json?query=*&facet=proxy_dc_contributor&profile=facets

Example: Requesting the default plus an additional individual facet

https://api.europeana.eu/record/v2/search.json?query=*&facet=DEFAULT+proxy_dc_contributor&profile=facets

Multiple Individual Facets

A client can request for one or more facet in one query. This can be done by either duplicating the facet parameter or by combining all the fields needed for faceting as a comma-separated String.

Example: a) requesting multiple facets by duplicating the facet parameter.

https://api.europeana.eu/record/v2/search.json?query=*&proxy_dc_coverage&facet=proxy_dc_contributor&profile=facets

Example: b) requesting multiple facets through a comma separated list.

https://api.europeana.eu/record/v2/search.json?query=*&facet=proxy_dc_coverage,proxy_dc_contributor&profile=facets

Offset and limit for Facets

A client can request how many facet values to retrieve, and which should be the first one. These parameters can be used to page over all facet values without requesting too many facet values at a time. The table below explains these two parameters. The FACET_NAME constant stands for the field for which the limit applies.

Example: Requesting for faceting on the PROVIDER field using offset and limit.

https://api.europeana.eu/record/v2/search.json?wskey=YOUR_KEY&query=paris&profile=facets&facet=PROVIDER&f.PROVIDER.facet.offset=10&f.PROVIDER.facet.limit=30

The Search API offers two ways of paginating through the result set: basic and cursor-based pagination. The basic pagination is suitable for smaller or user-facing browsing applications which allows for the iteration over the first 1000 results using the start parameter. For larger and/or harvesting applications, the API offers the capability to use cursor-based pagination which allows for a quick iteration over the entire result set.

Internally, Europeana uses Apache Solr platform to index its data and therefore Apache Lucene Query Syntax is inheritly supported by the Search API. Advanced users are encouraged to use Lucene and Apache SOLR guides to get the most out of the Europeana repository. For others, we supply a basic guide for querying Europeana.

Basic Search

To look for records that contain a search term in one of the data fields, provide the term as a query parameter:

Syntax: "Mona Lisa"

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query="Mona+Lisa"

Test on API Console

Note that like in many other search applications omitting the quotes will result in searching for records that contain the term Mona or the term Lisa but not necessarily both of them.

If you want to limit your search to a specific data field you should provide the name of the field using the following syntax. For example, to look for objects whose creator is Leonardo da Vinci:

Syntax: who:"Leonardo da Vinci"

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=who:"Leonardo+da+Vinci"

Test on API Console

Boolean Search

To combine several fields in one search one can use boolean operators AND, OR, and NOT (note the case-sensitivity). Use parentheses to group logical conditions. Note that two consecutive terms without any boolean operator in between default to the AND operator.

Syntax: mona AND lisa

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=mona+AND+lisa

Test on API Console

Boolean operators can also be combined with the search by fields. The following example searches for objects whose location is in Paris or in London:

Syntax: where:(Paris OR London)

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=where:(Paris+OR+London)

Test on API Console

The boolean NOT operator cannot be used alone but only in conjunction with another boolean operator. For example, looking for objects which contain the term Lisa but do not contain the term Mona is done by the following:

Syntax: lisa NOT mona

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=lisa+NOT+mona

Test on API Console

Range Search

To execute range queries, the range operator should be used. This example will search for objects whose field values fall between a and z:

Syntax: [a TO Z]

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=%5Ba+TO+z%5D

Test on API Console

As well as for textual fields it can also be used for numeric values, date ranges, or geographical areas, as shown below.

Geographical Bounding Box Search

To search for objects by their geographic location you should specify the bounding box of the area. You need to use the range operator and the pl_wgs84_pos_lat (latitude position) and pl_wgs84_pos_long (longitude position) field. The following example will bring all the objects found between the latitude of 45° and 47° and between the longitude of 7° and 8°:

Syntax: pl_wgs84_pos_lat:[45 TO 47] AND pl_wgs84_pos_long:[7 TO 8]

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=pl_wgs84_pos_lat:%5B45+TO+47%5D+AND+pl_wgs84_pos_long:%5B7+TO+8%5D

Test on API Console

Timestamp Search

One can also search objects by date. Currently, full-fledge date search is supported only for the fields storing the creation (timestamp_created) and update (timestamp_update) dates of the objects which are available in two formats: the UNIX epoch timestamp and the ISO 8601 formatted date. To search for objects created or updated on a given date, use the following query:

Syntax: timestamp_created:"2013-03-16T20:26:27.168Z"

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_created:"2013-03-16T20:26:27.168Z"

Test on API Console

Syntax: timestamp_update:"2013-03-16T20:26:27.168Z"

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_update:"2013-03-16T20:26:27.168Z"

Test on API Console

Searching for date range (as [date1 TO date2]):

Syntax: timestamp_created:[2013-11-01T00:00:0.000Z TO 2013-12-01T00:00:00.000Z]

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_created:%5B2013-11-01T00:00:0.000Z+TO+2013-12-01T00:00:00.000Z%5D

Test on API Console

Syntax: timestamp_update:[2013-11-01T00:00:0.000Z TO 2013-12-01T00:00:00.000Z]

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_update:%5B2013-11-01T00:00:0.000Z+TO+2013-12-01T00:00:00.000Z%5D

Test on API Console

Date mathematics

With date mathematics you can formulate questions, such as "in the last two months" of "in the previous week". The basic operations and their symbols are addition (+), substraction (-) and rounding (/). Some examples:

• now = NOW
• tomorrow: NOW+1DAY
• one week before now: NOW-1WEEK
• the start of current hour: /HOUR
• the start of current year: /YEAR

The date units are: YEAR, YEARS, MONTH, MONTHS, DAY, DAYS, DATE, HOUR, HOURS, MINUTE, MINUTES, SECOND, SECONDS, MILLI, MILLIS, MILLISECOND, MILLISECONDS (the plural, singular, and abbreviated forms refer to the same unit).

Let's see how to apply it in Europeana's context.

From xxx up until now

Syntax: timestamp_created:[xxx TO NOW]

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&&query=timestamp_created:%5B2014-05-01T00:00:00.000Z+TO+NOW%5D

Test on API Console

From xxx up until yesterday

Syntax: timestamp_created:[xxx TO NOW-1DAY]

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&&query=timestamp_created:%5B2014-05-01T00:00:00.000Z+TO+NOW-1DAY%5D

Test on API Console

Changes in the last two months

Syntax: [NOW-2MONTH/DAY TO NOW/DAY]

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&&query=timestamp_created:%5BNOW-2MONTH/DAY+TO+NOW/DAY%5D

Test on API Console

You can find more about data mathematics at Solr's API documentation

Query Refinements

So far we have dealt with examples where there was only one query term. Sometimes it is useful to split a query into a variable and a constant part. For instance, for an application that accesses only objects located in London, it is possible to have the constant part of the query pre-selecting London-based objects and the variable part selecting objects within this pre-selection.

This can be done using the refinement parameter qf which is appended to the query parameter. This example looks for objects which contain the term Westminster and their location is in London:

https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=Westminster&qf=where:London

Test on API Console

Refinement parameters can be concatenated. Each such parameter and the mandatory query parameter contributes a breadcrumb object if breadcrumbs are specified in the search profile.

The Search API offers an auxiliary method to help translate search terms to different languages so that they can be easily used with the main Search API method. This method uses the Wikipedia API to perform the actual translation. The signature of the method is as follows:

https://europeana.eu/api/v2/translateQuery.json?wskey=YOUR_KEY&term=TERM&languageCodes=LANGUAGE_CODES

The following parameters are supported by this method:

Response

A response of the translation method is always formated in JSON and will contain a number of fields that present information about the handling of the request, while the concrete information about the record is presented in the "translations" field.

Example: Get translations for "Notre Dame" in Dutch, English and Hungarian

https://europeana.eu/api/v2/translateQuery.json?languageCodes=nl,en,hu&wskey=YOUR_KEY&term=notre%20dame

For background information on this method, see the blog post Improving search across languages

Basic search function following the OpenSearch specification, returning the results in XML (RSS) format. This method does not support facet search or profiles. The names of parameters are different from other API call methods, because they match the OpenSearch standard. The OpenSearch response elements can be used by search engines to augment existing XML formats with search-related metadata. The signature of the method is as follows:

https://europeana.eu/api/v2/opensearch.rss?searchTerms=TERMS&count=COUNT&startIndex=START

The following parameters are supported by this method:

For the response, see OpenSearch specification.

Some fields available in API1 were renamed in API2. In the table below you can find the mapping between the old and the new field names. Old field names are still supported but we encourage using new names because the backward compatibility with API1 fields will be stopped at some point.