Places (Search) API Developer's Guide

Application Authentication

Applications must send credentials to identify themselves to the Places (Search) API when making requests. These credentials are a pair of values named app_id and app_code, which are obtained as described in Acquiring Credentials. They can be sent either as query string parameters, or using HTTP Basic Authentication.

Alternatively, enterprise and automotive applications may use OAuth 1.0 request signing to authenticate the application, and this is required when using premium features.

Query string parameter application authentication

Applications can send the app_id and app_code as query string parameters. Note that as with all query string parameters, the values should be URL-encoded when sent in this way. For example, the complete URL for a search request for "Italian pizza" in Berlin might look like this:
Note: Your application's requests will use its own unique app_id and app_code, rather the the ones above. To obtain the credentials for an application, see Acquiring Credentials.

HTTP Basic application authentication

Instead of sending the application credentials in URL query strings, the app_id and app_code can be sent in the Authorization header using the HTTP Basic Authentication Scheme.

The Authorization header is constructed as follows:

  • app_id and app_code are combined into a string "app_id:app_code"
  • The resulting string is then encoded using Base64
  • The Authorization method and a space, i.e. "Basic ", is then put before the encoded string.
Example of authorization header:
Header name Header value
Authorization Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Note: To use HTTP Basic application authentication your must send HTTPS requests.

When the application uses HTTP Basic Authentication the app_id and app_code query parameters can be omitted.

OAuth 1.0 Request Signing

To use premium features of the Places (Search) API, applications must sign requests using their app_id and a shared secret. OAuth 1.0 is used to sign all requests so that the client's identity can be verified.

When using request signing, the app_id and app_code should not be sent as query string parameters. Instead, the app_id is used as the value of oauth_consumer_key in the OAuth signature, and the signature is signed using the application's shared secret. The app_code is not needed at all when request signing is used.

Note: OAuth 1.0 supports authenticating both a client application and a user (or "resource owner") to the server. The Places (Search) API only uses OAuth 1.0 for application authentication, so there is no resource owner, and the oauth_token parameter should therefore be omitted when following the OAuth 1.0 procedure for Making Requests.

The Places (Search) API supports the following signature methods of OAuth 1.0:

Below is an example of an authorization header that uses the HMAC-SHA1 signature method:

Authorization: OAuth realm="Example",
Note: To use the PLAINTEXT OAuth Signature Method you must send https requests.

Below is an example of an authorization header that uses the PLAINTEXT signature method

Authorization: OAuth realm="Example",

You cannot use this account to purchase a commercial plan on Developer Portal, as it is already associated to plans with different payment methods.

To purchase a commercial plan on Developer Portal, please register for or sign in with a different HERE Account.

Something took longer than expected.

The project should be available soon under your projects page.

Sorry, our services are not available in this region.

Something seems to have gone wrong. Please try again later.

We've detected that your account is set to Australian Dollars (AUD).
Unfortunately, we do not offer checkouts in AUD anymore.
You can continue using your current plan as normal, but to subscribe to one of our new plans,
please register for a new HERE account or contact us for billing questions on