---
title: "Google Lsa Write Access"
method: GET
path: "/admin/lsa/write-access"
tags: ["admin", "lsa-admin"]
---

# Google Lsa Write Access

`GET /admin/lsa/write-access`

## Request

- Base URL: `https://api-docs.upsmith.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api-docs.upsmith.com/admin/lsa/write-access`
- Auth: one of:
  - API key in header `x-api-key`
  - HTTP bearer

Whether the org's Google Ads credential can actually reply on its LSA lead conversations.

A read-only OAuth grant still reads leads (it holds ACCESS_GLS_LEAD), so ingestion looks
healthy while every AppendLocalServicesLeadConversation is rejected. This reads
``customer_user_access`` per active account and reports whether any user holds ADMIN or
STANDARD — telling those two states apart without attempting a write.

Accounts served by a mapped MCC manager credential report ``manager_served`` with no
Google call. ``ok`` is false only for states a person must fix; a transient probe failure
leaves it true. Read-only; one Google Ads op per non-manager-served account, cached 24h
per org (``use_cache=false`` forces a fresh read).

## Query parameters

- `organization_id` string, required
- `use_cache` boolean

## Headers

- `organization-id` string, nullable
- `timezone` string
- `x-user-id` string, nullable
- `x-actor-email` string, nullable
- `x-request-source` string, nullable
- `x-operation-id` string, nullable
- `x-commit-message` string, nullable
- `x-confirmation-id` string, nullable
- `x-chat-id` string, nullable

## Response `200`

Successful Response

- GoogleLsaWriteAccessProbe: Can this org actually send LSA replies? ``ok`` is true only when every active account is verified able to reply (or has none to verify). ``no_write_access`` / ``no_credential`` / ``permission_denied`` / ``account_not_found`` are states a person must fix; ``rate_limited`` / ``provider_unavailable`` mean Google couldn't be asked, so the answer is unknown. Accounts served by an MCC manager credential report ``manager_served`` without a Google call: they authenticate as the manager, whose grant is not in the customer's own ``customer_user_access`` rows, so the direct-user roles say nothing about their write path.
  - `organization_id` string, required
  - `ok` boolean, required
  - `reason` 'ok' | 'no_accounts' | 'no_write_access' | 'no_credential' | 'permission_denied' | 'account_not_found' | 'rate_limited' | 'provider_unavailable', required
  - `accounts` GoogleLsaAccountWriteAccess[]
    - `google_customer_id` string, required
    - `ok` boolean, required
    - `reason` 'ok' | 'manager_served' | 'no_write_access' | 'no_credential' | 'permission_denied' | 'account_not_found' | 'rate_limited' | 'provider_unavailable', required
    - `detail` string, nullable: Human-readable explanation, populated when ok is false.
    - `granted_emails` string[]: Direct users holding ADMIN or STANDARD on the customer, when any do.
  - `checked_at` string, date-time, nullable: When this answer was actually obtained from Google (not when it was served).

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/upsmith/apis/upsmith-api.md) - [All operations](https://skmtc.dev/upsmith/apis/upsmith-api/llms.txt) - [OpenAPI document](https://skmtc.dev/upsmith/apis/upsmith-api/revisions/86e2c2bd93af?raw)