This documentation is no longer actively supported and may be out of date. Going forward, please visit and bookmark our new site (https://docs.phunware.com/) for up-to-date documentation.
Venue Audit History
Any resource (Venue, Campus, Building, Floor, Point, Segment, Resource, etc) that is added, modified, or deleted via the Mapping API should now generate an audit record in the database. In order to record user ID and username information in the audit history, the following request headers and appropriate values must be passed in each such request:
These audit history records can be retrieved via the following endpoint:
X-Auth (see Security)
userId - string
username - string
Any combination of orgId, isActive and/or clientId is accepted, but at least one must be present or the request is considered a bad request.
The unique identifier for the venue.
If "true", only the audit history for since the last "publish" operation will be retrieved. If "false" or not specified, all venue history will be retrieved for that venue. It is a bad request error to have both "sinceLastPublish" and "publishesOnly" set to true since they would be in conflict with each other.
If "true", only publish operations will be retrieved. It is a bad request error to have both "sinceLastPublish" and "publishesOnly" set to true since they would be in conflict with each other.
If set, only the audit history for a particular publish operation will be retrieved. If a "publishId" is given, then both "sinceLastPublish" and "publishesOnly" must be false or omitted; otherwise it is a bad request error since the query parameters would be in conflict with each other.
Example Query Fragment
URL-encoded, minified fragment:
A successful response will have a 200 status code and a body containing an array of audit history records that satisfy the query parameters:
See Mapping API Response Handling for error payloads.
Example body of a successful response: