canonical: https://jentic.com/apis/googleapis.com/sas-portal-testing

# Google SAS Portal API (Testing)

The SAS Portal API (Testing) is the Google Spectrum Access System staging surface used for managing CBRS (Citizens Broadband Radio Service) deployments, customers, nodes, devices, and installer workflows. It exposes operations for provisioning customer hierarchies, registering and validating CBSDs, signing devices, and managing deployment-level Google Cloud project bindings. The testing endpoint mirrors production semantics so integrators can exercise SAS workflows safely before promoting them to live spectrum operations.

## For AI agents

Manage CBRS Spectrum Access System deployments, devices, and customers in the Google SAS testing environment, including device signing and installer validation.

## Scope

Does not handle radio configuration, RF planning, or live production spectrum grants - use for Google SAS testing-environment customer, deployment, device, and installer management only.

## Capabilities

- Provision and migrate SAS customers, including legacy organizations and Google Cloud project deployments
- Register, validate, and sign CBSD devices for CBRS deployments under a customer hierarchy
- Manage SAS nodes and deployments to mirror real-world tower or campus topologies
- Generate and validate installer secrets for technicians commissioning CBRS radios
- Get and set IAM-style policies that govern access to SAS resources
- Run dry-run migrations and analytics setup for SAS customers ahead of production cutover

## Use cases

### CBRS Deployment Staging

Use the testing SAS Portal to stage and rehearse CBRS deployments before promoting them to production. Operators can create representative customers, nodes, and devices, then exercise the full installer and validation flow without affecting live spectrum allocation.

Example prompt: Create a SAS customer, attach a deployment to a Google Cloud project, register a CBSD with serial number TEST-1234, and validate an installer secret end-to-end.

### Installer Workflow Automation

Field installation of CBRS radios requires generating short-lived installer secrets and validating them when the technician registers the device on site. The SAS Portal API exposes both halves of this flow so it can be wired into work order systems.

Example prompt: Call /v1alpha1/installer:generateSecret, deliver the secret to the technician via SMS, then later call /v1alpha1/installer:validate when they confirm the device is on site.

### Customer Onboarding and Migration

Onboarding a new SAS customer involves creating the customer record, provisioning a deployment bound to a Google Cloud project, optionally migrating from a legacy organization, and setting up analytics. The API exposes each of these steps as discrete operations so onboarding can be automated.

Example prompt: Create a new SAS customer for a wireless ISP, call customers:provisionDeployment to bind a Google Cloud project, then call customers:setupSasAnalytics to enable reporting.

### Agent-Driven SAS Test Harness

An AI agent rehearses CBRS deployment scenarios in the SAS testing environment via Jentic, exercising customer creation, device registration, signing, and policy retrieval to validate that orchestration logic behaves correctly before pointing at production.

Example prompt: Search Jentic for register a CBSD device, load the schema, and execute a dry-run registration against the testing endpoint with synthetic device parameters.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1alpha1/customers:provisionDeployment | Provision a deployment for a customer |
| POST | /v1alpha1/customers:migrateOrganization | Migrate a legacy organization into the SAS hierarchy |
| POST | /v1alpha1/customers:setupSasAnalytics | Enable SAS analytics for a customer |
| POST | /v1alpha1/installer:generateSecret | Generate a short-lived installer secret |
| POST | /v1alpha1/installer:validate | Validate an installer secret on site |
| POST | /v1alpha1/policies:set | Set the access policy on a SAS resource |

## Key resources

- **customers** — Top-level SAS customer accounts and their migration and deployment operations
- **deployments** — SAS deployments bound to Google Cloud projects under a customer
- **nodes** — Logical SAS nodes representing sites or organizational subgroups
- **installer** — Generate and validate short-lived installer secrets for field technicians
- **policies** — Get and set access policies on SAS resources

## Why Jentic

- **Setup:** Wiring the SAS Portal testing API by hand means configuring Google OAuth 2.0, minting scoped access tokens, and threading customer, deployment, and installer resource names through the v1alpha1 endpoints on prod-tt-sasportal.googleapis.com. Through Jentic you install once, import the SAS Portal testing API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** This API carries the customer, deployment, and installer identifiers in the URL path, so a rule can pin your agent to one customer or deployment: it can provision and list within that scope and nothing else. You choose the operations it may call, so state-changing ones like migrating an organization or setting a policy are not included unless you add them.
- **Credential handling:** Your Google OAuth credential is stored once, encrypted, by your own Jentic One instance and a scoped access token is injected at execution time. The credential never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'provision a SAS deployment' or 'generate an installer secret', and Jentic returns the matching SAS Portal testing operation with its input schema so the agent calls the right endpoint without navigating the alpha discovery doc.

## Related APIs

- **Identity and Access Management API** — Manages the Google Cloud IAM identities that bind to SAS deployments
- **Cloud Key Management Service API** — Stores and rotates the cryptographic keys used to sign SAS device certificates
- **Certificate Authority API** — Issues private certificates used by CBSDs in custom PKI hierarchies

## FAQ

### What authentication does the SAS Portal API (Testing) use?

The API uses Google OAuth 2.0 with the userinfo.email and SAS-specific scopes documented by Google. Through Jentic the OAuth credentials live in the vault and short-lived access tokens are injected into requests so the underlying client secret never reaches the agent.

### Is this API safe to use against live spectrum?

No, this is the testing surface (prod-tt) and is intended for integration rehearsal only. Use it to validate registration, validation, and installer flows; switch to the production SAS Portal API endpoint when promoting code to live CBRS deployments.

### How do I register a CBSD device through Jentic?

Search Jentic for register a CBSD device, load the schema for the SAS Portal customers.devices create operation under /v1alpha1/{+parent}/devices, and execute it with the device serial number, FCC ID, and installation parameters from your provisioning system.

### What are the rate limits for the SAS Portal API?

Quotas are configured per Google Cloud project under the SAS Portal service. The testing endpoint is intended for low-volume integration work and does not guarantee production-level throughput, so batch heavy onboarding runs.

### Can I migrate a legacy organization through this API?

Yes, call POST /v1alpha1/customers:listLegacyOrganizations to find candidates, then POST /v1alpha1/customers:migrateOrganization to migrate them into the SAS customer hierarchy. Run this against the testing endpoint first to confirm the resulting topology before touching production.

### How do I validate an installer secret?

Generate the secret with POST /v1alpha1/installer:generateSecret, deliver it to the technician, then call POST /v1alpha1/installer:validate with the same secret on site to authorize the installation.

### Can I limit what my agent is allowed to do with the SAS Portal API (Testing)?

Yes. Because you run Jentic One yourself, your own rules decide which SAS Portal operations and which OAuth credential the agent may use, and the customer, deployment, and installer identifiers travel in the URL path, so a rule can pin the agent to a single customer or deployment and let it only provision and list within that scope. You pick the operations it may call, so state-changing ones like customers:migrateOrganization or policies:set stay off limits unless you add them. That lets you allow safe read and registration flows such as customers.devices create or installer:validate while blocking anything that reshapes the SAS hierarchy.