API calls for all endpoints tagged Beaconinfo

API calls for all endpoints tagged Beacons

API calls for all endpoints tagged Namespaces

API calls for all endpoints tagged V1beta1

Handle Tesla connections for GoogleApi.ProximityBeacon.V1beta1

Helper functions for deserializing responses into models

Defines a unique identifier of a beacon as broadcast by the device

A subset of attachment information served via the `beaconinfo.getforobserved` method, used when your users encounter your beacons

Details of a beacon device

Project-specific data associated with a beacon

A subset of beacon information served via the `beaconinfo.getforobserved` method, which you call when users of your app encounter your beacons

Response for a request to delete attachments

Diagnostics for a single beacon

A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method. For instance: service Foo { rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); } The JSON representation for `Empty` is empty JSON object `{}`

Write-only registration parameters for beacons using Eddystone-EID format. Two ways of securely registering an Eddystone-EID beacon with the service are supported: 1. Perform an ECDH key exchange via this API, including a previous call to `GET /v1beta1/eidparams`. In this case the fields `beacon_ecdh_public_key` and `service_ecdh_public_key` should be populated and `beacon_identity_key` should not be populated. This method ensures that only the two parties in the ECDH key exchange can compute the identity key, which becomes a secret between them. 2. Derive or obtain the beacon's identity key via other secure means (perhaps an ECDH key exchange between the beacon and a mobile device or any other secure method), and then submit the resulting identity key to the service. In this case `beacon_identity_key` field should be populated, and neither of `beacon_ecdh_public_key` nor `service_ecdh_public_key` fields should be. The security of this method depends on how securely the parties involved (in particular the bluetooth client) handle the identity key, and obviously on how securely the identity key was generated. See the Eddystone specification at GitHub

Information a client needs to provision and register beacons that broadcast Eddystone-EID format beacon IDs, using Elliptic curve Diffie-Hellman key exchange. See the Eddystone specification at GitHub

Request for beacon and attachment information about beacons that a mobile client has encountered "in the wild"

Information about the requested beacons, optionally including attachment data

Indoor level, a human-readable string as returned by Google Maps APIs, useful to indicate which floor of a building a beacon is located on

An object representing a latitude/longitude pair. This is expressed as a pair of doubles representing degrees latitude and degrees longitude. Unless specified otherwise, this must conform to the <a href="http://www.unoosa.org/pdf/icg/2012/template/WGS_84.pdf">WGS84 standard</a>. Values must be within normalized ranges. Example of normalization code in Python: def NormalizeLongitude(longitude): """Wraps decimal degrees longitude to [-180.0, 180.0].""" q, r = divmod(longitude, 360.0) if r > 180.0 or (r == 180.0 and q <= -1.0): return r - 360.0 return r def NormalizeLatLng(latitude, longitude): """Wraps decimal degrees latitude and longitude to [-90.0, 90.0] and [-180.0, 180.0], respectively.""" r = latitude % 360.0 if r <= 90.0: return r, NormalizeLongitude(longitude) elif r >= 270.0: return r - 360, NormalizeLongitude(longitude) else: return 180 - r, NormalizeLongitude(longitude + 180.0) assert 180.0 == NormalizeLongitude(180.0) assert -180.0 == NormalizeLongitude(-180.0) assert -179.0 == NormalizeLongitude(181.0) assert (0.0, 0.0) == NormalizeLatLng(360.0, 0.0) assert (0.0, 0.0) == NormalizeLatLng(-360.0, 0.0) assert (85.0, 180.0) == NormalizeLatLng(95.0, 0.0) assert (-85.0, -170.0) == NormalizeLatLng(-95.0, 10.0) assert (90.0, 10.0) == NormalizeLatLng(90.0, 10.0) assert (-90.0, -10.0) == NormalizeLatLng(-90.0, -10.0) assert (0.0, -170.0) == NormalizeLatLng(-180.0, 10.0) assert (0.0, -170.0) == NormalizeLatLng(180.0, 10.0) assert (-90.0, 10.0) == NormalizeLatLng(270.0, 10.0) assert (90.0, 10.0) == NormalizeLatLng(-270.0, 10.0)

Response to `ListBeaconAttachments` that contains the requested attachments

Response that contains list beacon results and pagination help

Response that contains the requested diagnostics

Response to ListNamespacesRequest that contains all the project's namespaces

An attachment namespace defines read and write access for all the attachments created under it. Each namespace is globally unique, and owned by one project which is the only project that can create attachments under it

Represents one beacon observed once

Helper functions for building Tesla requests