Customer API · Developers

Customer API applications, credentials, scopes, and webhooks

Use API Access for customer administration; use developer.smartq.tv as the authoritative endpoint and schema reference.

Verified 2026-09-07 · Source 7d700cc3

What this does

Use API Access for customer administration; use developer.smartq.tv as the authoritative endpoint and schema reference.

Steps

Select the intended group or location, then open Settings > API Access.
Choose Create Application and enter a recognizable application name.
Select available Module Access choices. Location context limits creation to that location; group context uses the group. Permitted operations, expiration and rate limit come from your API grant, not free-form fields in this dialog.
If Reviews is selected and your grant permits it, review the separate reply-operations checkbox. This does not authorize Google Customer API publishing.
Review and accept the current Customer API Terms, then choose Accept & Create Application.
Securely save the Client ID and one-time Client Secret. Never paste secrets into Support or documentation screenshots.

Client ID, Client Secret, and OAuth

Client ID identifies the application. Client Secret authenticates token requests and is distinct from legacy credentials. Use OAuth client credentials exactly as documented in the Developer Portal.

Revoke

Revocation stops new access tokens and can immediately interrupt dependent integrations. It does not convert legacy credentials.

Customer creation controls and inherited scope

The customer wizard has three steps: Application name, Module access, and Customer API Terms. Name must be nonblank. Select at least one available module; occupied modules show their overlapping-location conflict. Scope comes from the selected group/location, and operation permissions, expiration and rate limit are inherited from the API grant. The customer wizard does not expose the internal tool's scope list, location subset, expiration picker or rate-limit input. Backend authorization remains authoritative even if a module appears in the UI. Terms must load and match the current version before issuance. This control is covered by the Customer API applications, credentials, scopes, and webhooks workflow.

Reviews reply opt-in and provider limits

Reviews reply operations are separate from module selection and appear only when the displayed grant includes reviews:reply:write. The checkbox initializes off when the page mounts; inspect its value when reopening the dialog because the current close/success handlers do not reset it. A reply grant does not bypass provider restrictions: Google Customer API content reads and publishing remain policy-gated. See Reviews Customer API and webhooks for the provider-neutral contract.

Webhook destination lifecycle and save behavior

Choose an active client-credentials application with bevq:read or reviews:read. Location-context customers can manage matching location applications here, not group applications. Events are limited by application scope; at least one supported event is required. Changing Application resets the draft name, URL, events, enabled value and scope. HTTPS destination is required on creation; leaving it blank during editing preserves the existing private URL. All authorized locations respects the application allowlist; unrestricted group grants can include future authorized locations. Selected locations requires a nonempty subset and does not add future locations. Enabled is a draft value until Save webhook. Rotate secret writes immediately and invalidates the previous secret without an overlap period. Send test queues a synthetic external delivery: queue success does not prove delivery or a real Reviews event. Remove requires confirmation and stops future deliveries. Never use these write actions merely to stage a screenshot.

Settings reference

Setting	What it does	Default	Scope	Notes
Module Access	Selects available product modules	None	Application	Module ownership and active API grant restrict choices.
Group/location scope	Constrains application locations	Selected context	Inherited	Not a location-subset picker in customer creation.
Operations, expiry and rate limit	Bounds permitted access	Current API grant	Inherited	Not free-form customer creation controls; server validates the active grant.
Modules, scopes, and locations	Configures modules, scopes, and locations.	Current product default shown in the UI	group or location	Requires settings editor; displayed choices are authoritative for the current account and release.

Permissions and scope

No Access hides or blocks the module. Read Only permits viewing but disables changes. Editor permits the documented create, edit, publish, or administrative actions within the user's assigned scope.

Mobile

On narrow screens, open the sidebar or overflow menu to reach the same actions; labels and save behavior are unchanged unless this article says otherwise.

Application list and legacy credentials

This control is covered by the Customer API applications, credentials, scopes, and webhooks workflow.