API Reference

This page provides reference documentation for the Metrics Configuration Generator (MCG) API endpoints.

Endpoints overview

The following sections detail the API endpoints available in MCG.

Metrics configuration

Vehicle Signal Catalogs

Service status

Protobuf content types

Several API endpoints accept or return data in protocol buffer (protobuf) format. Two content types are used:

  • application/x-protobuf: Indicates protobuf data in its binary wire format. This format is efficient for machine-to-machine communication but isn't human readable.
  • text/x-protobuf: Indicates protobuf data in its text format, which is human readable and useful for debugging or manual inspection.

When an endpoint supports multiple protobuf formats for a request or response, use the Content-Type header to specify the format of request data, and the Accept header to specify the selected format of response data. For example:

  • -H 'Content-Type: application/x-protobuf'
  • -H 'Accept: text/x-protobuf'

Call the API

The examples on this page use curl for calling the REST API and assume you set the SERVICE_URL environment variable to refer to the host where MCG is deployed. When running locally, this is usually http://localhost:8005.

To target a remote Cloud Run instance, set SERVICE_URL using gcloud. Then, append an authorization header with an OpenID Connect (OIDC) identity token to your curl command:

SERVICE_URL=$(gcloud run services describe mcg-service --region=<var label="Google Cloud region">GCP_REGION</var> --format='value(status.url)')

# Authorization header to append to curl command:
-H "Authorization: Bearer $(gcloud auth print-identity-token)"

Metrics configuration

This section describes endpoints for generating and validating metrics configurations.

POST /api/v1/generate_metrics_config

Create a MetricsConfig instance from metrics configuration request details. This process includes validation, and if generation fails due to schema violations, invalid references, cyclic dependencies, or other issues, the API returns a list of error details.

Endpoint details
Query parameters ignore_validation: boolean
Optional. If true, ignore validation errors and return MetricsConfig.
Request body The request body must contain metrics configuration request details in JSON format.
Success response The response body contains a MetricsConfig message in application/x-protobuf or text/x-protobuf format.
The Metrics-Config-Size header contains the configuration size in bytes.
Example
curl -H "Content-Type: application/json" \
  -H "Accept: text/x-protobuf" \
  --data-binary @PATH_TO_METRICS_CONFIG_JSON \
  "$SERVICE_URL/api/v1/generate_metrics_config"
      

POST /api/v1/get_file_descriptor_set

Return file descriptors for a given MetricsConfig for decoding reports.

Endpoint details
Request body The request body must contain an android.sdv.telemetry.MetricsConfig message in application/x-protobuf or text/x-protobuf format.
Success response The response body contains a google.protobuf.FileDescriptorSet message in application/x-protobuf or text/x-protobuf format.
Example
curl -H "Content-Type: application/x-protobuf" \
  -H "Accept: application/x-protobuf" \
  --data-binary @PATH_TO_METRICS_CONFIG_PB \
  "$SERVICE_URL/api/v1/get_file_descriptor_set"
      

POST /api/v1/validate_metrics_config

Validate the provided MetricsConfig, returning a list of any validation errors.

Endpoint details
Query parameters return_config: boolean
Optional. If true, return MetricsConfig upon successful validation.
Request body The request body must contain an android.sdv.telemetry.MetricsConfig message in application/x-protobuf or text/x-protobuf format.
Success response The response body contains an empty object (default) or MetricsConfig (if return_config is true).
The Metrics-Config-Size header contains the configuration size in bytes.
Example
curl -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  --data-binary @PATH_TO_METRICS_CONFIG_JSON \
  "$SERVICE_URL/api/v1/validate_metrics_config"
      

Vehicle Signal Catalogs

This section describes endpoints for managing Vehicle Signal Catalogs.

POST /api/v1/vs/

Create new or update existing Vehicle Signal Catalog.

Endpoint details
Request body The request body must contain a JSON object with a version string and a base64-encoded FileDescriptorSet for vehicle_signals.
{
  "version": "string",
  "vehicle_signals": "string"
}
Success response If successful, the API returns application/json with the version of the catalog that was added or updated:
{"version": "string"}
Example For instructions on generating the base64-encoded FileDescriptorSet for the vehicle_signals field, see Vehicle Signal Catalogs.
curl -H "Content-Type: application/json" \
  --data-binary @- "$SERVICE_URL/api/v1/vs/" << EOF
{
  "version": "v1.0",
  "vehicle_signals": "VEHICLE_SIGNALS_BASE64"
}
EOF
      

GET /api/v1/vs/

List all Vehicle Signal Catalog metadata.

Endpoint details
Success response If successful, the API returns application/json containing a list of catalog versions:
{"versions": [{"version": "string"}]}
Example
curl "$SERVICE_URL/api/v1/vs/"
      

DELETE /api/v1/vs/{version}

Delete the specified Vehicle Signal Catalog.

Endpoint details
Path parameters version: string
Required. The identifier of the Vehicle Signal Catalog to delete, as provided in the version field of the POST request.
Success response If successful, the API returns application/json with the version of the catalog that was deleted:
{"version": "string"}
Example
curl --request DELETE "$SERVICE_URL/api/v1/vs/v1.0"
      

Service status

This section describes endpoints for checking service health.

GET /health

Check the service's health.

Endpoint details
Success response If healthy, the service returns a 200 OK status code.
Example
curl "$SERVICE_URL/health"
      

Error responses

When an API call results in an error (HTTP status 4xx or 5xx), the response body contains an error object with the following structure:

{
  "error": {
    "code": 400,
    "status": "INVALID_ARGUMENT",
    "message": "Request validation failed",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.BadRequest",
        "fieldViolations": [
          {
            "field": "fieldName",
            "description": "error description"
          }
        ]
      }
    ]
  }
}
Error fields
code int32
The HTTP status code (for example, 400, 404, or 500).
status string
The Google RPC canonical status code (for example, INVALID_ARGUMENT, NOT_FOUND, or INTERNAL).
message string
A developer-facing error message in English.
details Array<object>
An array of objects containing further error details, identified by their @type member.