google_api_proximity_beacon v0.2.0 API Reference

Modules

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.

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.

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.