AI Studio Product API

AI Studio does not expose one documented REST management endpoint that covers every product object. The programmatic integration paths currently described in this documentation are:

  • Publish a system or custom operator from Catalog as a REST service.

  • Use connection details generated by Catalog to query data from a MySQL-compatible client.

  • Load external data through a REST API or GraphQL connector.

  • Deliver processing results, or events that a deployment makes available, to an external service through a Webhook.

This quickstart uses the most direct path: an Operator API. Its URL, request fields, and response shape come from the published operator’s configuration and signature. They are not a universal contract shared by every service.

Check the service before publishing

You need a runnable operator in the target AI Studio workspace and permission to publish and use that resource. Confirm the following when publishing:

  1. The names and types of its inputs, including required fields and defaults.

  2. Whether the service uses an API Key, OAuth 2.0, or public access.

  3. Runtime limits such as timeout, maximum concurrency, and call frequency.

  4. The compute resource or model service required by the operator is available.

Copy the complete endpoint from the operator details under API Service, and treat the request description shown there as the contract. If your UI has no publishing or API service entry, permissions, deployment mode, or feature flags might differ. Do not substitute an internal URL captured from browser developer tools.

Set the call parameters

The example below assumes API Key authentication. A Genesis API Key can be selected as a default authentication option for an Operator API, but the published service configuration is authoritative.

export OPERATOR_ENDPOINT='https://<full-operator-endpoint>'
export OPERATOR_API_KEY='<api-key-configured-for-this-service>'

OPERATOR_ENDPOINT must be the complete address copied from the service details. Do not append a guessed version or path.

Build the request from the operator signature

If the published operator declares one string parameter named input, a request can look like this:

curl --fail-with-body --silent --show-error \
  "$OPERATOR_ENDPOINT" \
  -X POST \
  -H "Authorization: Bearer $OPERATOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Content to process"
  }'

The input field is only an example. A real service can require several fields, different types, or a nested body. Match the request example on its API Service page. The response is likewise determined by the operator’s output signature; do not assume that the result is always under data, result, or any other fixed field.

For a service configured with public access, omit the authentication header as directed by the page. For OAuth 2.0, obtain an access token from the configured authorization server first. Do not send multiple credential types in one request.

Validate the integration

Use the page’s test facility or a minimal curl call before adding the endpoint to an application. Check at least the following:

Check

Expected result

HTTP status

A success status; retain the response body when diagnosing a failure

Output shape

Matches the output signature of the current operator version

Authentication

Uses the method selected at publication, without logging the Key or token

Runtime limits

Latency, concurrency, and call frequency remain within the service configuration

Version changes

Callers are updated and tested again after an input or output signature changes

Operator calls are synchronous. For long-running or multi-step processing, compose a workflow and use the job status or Webhook facilities available in the product. Do not assume an operator endpoint automatically returns an asynchronous job ID.

Choose another integration path

Requirement

Appropriate entry point

Query Catalog tables from a BI tool, database client, or driver

Use the SQL connection details generated by Catalog; obtain the exact host, port, user, password, and database from the console

Read a third-party HTTP API on a schedule

Configure a REST API or GraphQL source and a load job

Push processing results to an external service

Configure a Webhook and validate its source with the signing method actually provided

Call chat, embedding, or reranking models directly

Use the Genesis API, not a Product API detour

Manage knowledge bases, agents, or workflows

Use only APIs explicitly published by your deployment; this documentation does not yet specify a stable unified OpenAPI