Location Labs

  • Company
  • Products
  • Blog
  • Facebook
  • Twitter
  • YouTube
[icon] Universal Location Service

Universal Location Service

  • Overview
  • My Apps
  • Tutorials
  • Test Tools
  • SDK
  • Developer Guide
  • Billing
  • Support
  • Register
  • Sign In

Developer Guide

  • 1.0 About Veriplace
  • 2.0 Getting Started
  • 3.0 Using the User Discovery API
  • 4.0 Using the Get Location API
  • 5.0 Using the Past Location API
  • 6.0 Using the Verify Permission API
  • 7.0 Using the Permission Delete API
  • 8.0 Using the Get Permissions API
  • 9.0 Using the Invitation API
  • 10.0 Using the Polling API
  • 11.0 Using the Verify Locatability API
  • 12.0 Previous API versions
  • Veriplace XML Schema
  • Disclaimer
  • OAuth Core 1.0 Rev A

Using the Past Location API

5.0 Using the Past Location API

You can use the Past Location API to obtain location that you obtained previously for a specific Veriplace user.

Before using the Past Location API, you must posses a Veriplace user identifier, a Veriplace location identifier, and an Access Token permitting you to obtain the user's  location.

5.1 About Past Location

Every location returned by Veriplace includes a unique identifier. Developers may access previously obtained location information in real time using this identifier.

The Past Location API  exists primarily to relieve applications of the responsibility of storing location data.

5.2 Retrieving Past Location

Veriplace represents past location information as an HTTP GET to the following resource URL:

https://veriplace.com/api/1.1/users/<userID>/locations/<locationID>

Requests must be signed using HMAC-SHA1 and an Access Token permitting you to locate the user.

You may also add either or both of the following query string parameters to query related location information, as described in 4.2.9 Points of Interest and Street Intersections:

  • withNearestPOI=true
  • withNearestIntersection=true

You can query this information even if the original location request did not include those parameters, but note that the query may not succeed (in which case the corresponding elements will not appear in the location response), and that the street intersection parameter is not enabled for all applications.

5.2.1 Common Failure Conditions

Past location data will not be available after it expires or if the user manually deletes it.

5.3 Successful Requests

On success, you will receive an HTTP 200 ("OK") code, and a location response in the same format used by the Get Location API.

5.4 Unsuccessful Requests

In accordance with the HTTP Response Codes section of the OAuth specification, you will receive an HTTP 400 ("Bad Request") or 401 ("Unauthorized") code if something went wrong with the OAuth signature.  In some cases, a 401 error code will be accompanied by the reason phrase "Invalid / non-monotonic timestamp", which is commonly a sign that your system clock is misconfigured.

Developers

  • Developer Terms of Service
  • Privacy Policy
  • Content Requirements
  • Trademark Schedule
  • Forum

End Users

  • Terms of Service
  • Privacy Policy
  • Support

Follow Us

  • [icon] Facebook
    Facebook
  • [icon] Twitter
    Twitter
  • [icon] YouTube
    YouTube

Location Labs

info@location-labs.com

© 2010 Location Labs

All rights reserved.