API access and the GraphQL explorer
Delivery is read-only over REST, GraphQL, JSON-RPC and the JavaScript/TypeScript SDK. Studio authentication and external delivery credentials have different authority.
How to use it
- The Owner opens API access and creates an environment-bound credential for the intended application.
- Prefer scoped application tokens with the minimum model/language/media and published-or-preview access needed. Save one-time secrets in server configuration.
- Use the copy controls for displayed public values; regenerate/rotate a lost secret deliberately and update consuming apps.
- Open GraphQL explorer to build authenticated queries. Its runtime loads on demand; retry if the module fails to load.
Good practice
- Keep preview credentials on the server and revoke an app's token when its access ends.
Avoid
- Neither a public key nor a preview token is a content-management write credential. Do not embed preview secrets in browser code.
Signed webhooks and delivery history
Webhooks notify a receiver after content transactions commit. Delivery is at least once, with bounded retries and a private attempt history.
How to use it
- Open Webhooks with webhook-management access and add an approved HTTPS receiver plus event subscriptions.
- Save the signing secret securely and configure the receiver to verify the raw-body signature and deduplicate event IDs.
- Inspect delivery and attempt outcomes, response status and retry timing in the studio.
- Fix permanent receiver failures before explicitly retrying a failed delivery; rotate the signing secret when appropriate.
Good practice
- Acknowledge quickly, queue expensive work on the receiver and make processing idempotent.
Avoid
- Do not assume exactly-once delivery, publish secret entry values in logs or disable signature verification to fix a failing receiver.
Enrich entries from a read-only REST source
One authorized-manager-approved REST source per environment can attach live external fields. Remote values are separate from editorial snapshots and are fetched only when a delivery request opts in.
How to use it
- Ask the operator to allow the exact public HTTPS host and configure any server-held credential reference.
- Open Remote sources, choose the local model and non-translated stable external-ID field, then map only approved remote values.
- Review and approve the endpoint/mappings, enable the source and test a linked entry.
- Request includeRemote through the supported delivery interface and inspect remote metadata or failure state. Pause the source to stop enrichment.
Good practice
- Use imports instead when external values must become reviewed, versioned editorial content.
Avoid
- Publishing a local entry does not freeze a live upstream value. Do not use private network targets, arbitrary credentials or write endpoints.
Slack publication notifications
The built-in Slack connector sends fixed metadata notifications to an intended channel, independently of signed webhooks.
How to use it
- Open Integrations as the Owner, create a Slack connection and enter that channel's incoming webhook URL.
- Choose events with labelled checkboxes. Saving does not send a test message.
- Use Send test message explicitly, then Refresh activity to inspect queued/delivered/retrying/failed outcomes.
- Pause or remove a connection when it is no longer needed.
Good practice
- Use a designated test channel first; treat the webhook URL as a secret.
Avoid
- Do not expect a sent message to be recalled by pausing the connection; ambiguous retries can create duplicates.
Shopify, WooCommerce and Clover catalog links
Built-in read-only catalog connections let authorized editors link external products to local content. They do not synchronize orders, payments, stock mutations or customer data.
How to use it
- The operator registers provider apps/callbacks and credentials where required; the Owner creates a connection in the correct environment.
- For Shopify authorize the intended myshopify.com store with the configured read-only product scope. For WooCommerce enter the HTTPS store and Read API credentials, then Test and enable.
- For Clover choose the merchant and correct Sandbox/region, then authorize the registered app with Read inventory permission. Start with a designated test merchant.
- Enable approved models/languages for linking, search the catalog, select the intended product and save the local entry.
- Inspect connection activity, reconnect expired/revoked credentials and remove obsolete connections to release plan capacity.
Good practice
- Use stable external IDs; independently verify the provider's real installation and distribution requirements.
Avoid
- A saved product link is not a frozen price/inventory snapshot. Local test success does not establish provider production approval.
Operator-installed catalog extensions
Operators can install reviewed read-only catalog extensions. Owners configure and enable them per environment using the existing Integrations page and quota. Custom fields, executable uploads, arbitrary tool builders and a marketplace are not implemented.
How to use it
- Ask the instance operator to install a compiled Cms.Integrations.Extension implementation with a supported v1 manifest, fixed HTTPS host/path and pure mapping callbacks. Registering code is an operator responsibility, not a Studio upload.
- In Integrations, choose the installed service, enter its declared settings and server token, add the connection, then Test and enable. Each pending or paused connection uses one integration slot in the selected environment.
- Connect a non-translated text field. Authorized editors search and select products in the shared picker; entries and delivery keep only the stable external ID.
- For configuration or an operator upgrade, open Settings, review the displayed installed version, confirm the checkbox and save, then test again. Leaving the replacement token blank keeps the existing token.
- Pause/remove a connection to stop reads. Uninstalled or changed implementations block warm-cache reads too; saved IDs, local drafts, published snapshots and history remain intact. Ask the operator to restore compatible code or review the new configuration.
Good practice
- Keep trusted operator code and customer configuration clearly separated. Put credentials only in the token field, never settings or URLs. Actual provider setup requires separate qualification.
Avoid
- Do not upload executable code expecting a sandbox: installed modules run as trusted server code. The bundled inventory example uses a reserved hostname for fixtures, not a live service. Custom scalar-field extensions remain planned.