Places (Search) API Developer's Guide

Client Activity Tracking

Applications using Places (Search) API must enable services to log user activities such as search requests, search result choices and other interactions.

Activity Tracking aims to improve the future Search & Discovery experience for the user. This feature is based on anonymously provided data about user activities such as search requests. More specifically Places (Search) API relies on feedback from users in order to improve the statistical model it uses for building relationships between places, ranking places and providing recommendations. This data also helps HERE to debug customers' technical issues.

To this end, client applications should send certain tracking data with each request they make. The data is anonymous and the purpose is not to track individual users but to improve the results from the Places (Search) API. For detailed information for how to appropriately track client activity, see below:

Cookies

Cookies are small pieces of data sent from services like the Places (Search) API to its clients in HTTP response headers. The client application remembers this data, and when it later uses the same service, it sends the cookie data back to the service. This is used to correlate different requests from the same user.

Client applications using the Places (Search) API are required to support cookies. The Places (Search) API uses two cookies called NLP.PS and NLP.PP, which are sent in Set_Cookie response headers. The application should then send these cookies in Cookie request headers with each subsequent request until the date provided in the Expires field of the cookie. If such a date is not present, the cookie should be sent only until the end of the session. While cookie handling can be manually implemented, most HTTP libraries have built in support for it.

If the client application sends the DNT (Do Not Track) header to the Places (Search) API, then Places (Search) API will not use information from cookies to track user activities, but might use them for other technical purposes.

X-Forwarded-For Header

The X-Forwarded-For header should be provided in line with the Internet Engineering Task Force (IETF) Forwarded HTTP Extension specification.

If requests from the client application are generated on a server rather than the user's device, the server should send the client's IP address in the X-Forwarded-For header.

User-Agent Header

The User-Agent. in header should be provided to the Places (Search) API.

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 selfservesupport@here.com.