Skip to content

Expedition. Free, virtual, Nov 3–6.

Technical tracks for practitioners, outcomes for leaders.

Register now
Snowflake for Developers/Developer Blog/Calling OpenAI- and Anthropic-compatible APIs through one governed Snowflake endpoint

Calling OpenAI- and Anthropic-compatible APIs through one governed Snowflake endpoint

Compliance, Security, Discovery & Governance
Navnit Shukla

Builders already use familiar OpenAI and Anthropic clients to put AI into production. The hard part is operating those applications responsibly: teams operating AI applications in production need to consider model choice, credentials, access policy, spend controls, and auditability.

Cortex AI Gateway gives builders one governed endpoint inside Snowflake. Point an existing Chat Completions or Messages client at the gateway URL, then apply Snowflake access control, tracing, and quotas without rewriting the application's inference logic. The result is a familiar developer experience with Snowflake controls around it. Without a shared gateway, teams may manage provider credentials and usage visibility separately.

This 2 part series covers:

  • Builder path: discover the endpoint and send your first request with OpenAI-compatible Chat Completions and Anthropic Messages APIs.
  • Admin path: configure the gateway specification, observe traffic, and add a small test quota.

This post is the builder path: first inference in a few minutes.

Step 1: Discover the governed endpoint with SHOW AI GATEWAYS

Run this in a Snowflake worksheet:

SHOW AI GATEWAYS;

Copy the base_url returned for the gateway you want to use.

Don't construct the URL by hand, and don't append /v1 to BASE_URL. The examples below append the API path.

A default gateway looks like this:

https://<account-identifier>.snowflakecomputing.com/api/v2/aigateways/SNOWFLAKE

Step 2: Create a programmatic access token (PAT)

In Snowsight, open Settings → Authentication → Programmatic Access Tokens, generate a token, choose the role it will use, and store it securely. Snowflake doesn't show the token again.

The request header is:

Authorization: Bearer <programmatic-access-token>

For production, use a dedicated service identity and the least-privileged role that can call the gateway.

Step 3: Set environment variables for the gateway URL and models

Set the values used by the examples:

export PAT="<your-programmatic-access-token>"
export BASE_URL="<base_url-from-SHOW-AI-GATEWAYS>"
export MODEL="<model-from-your-gateway-spec>"
export CLAUDE_MODEL="<Claude-model-from-your-gateway-spec>"

Choose model IDs from the gateway's current specification.

A model that appears in public documentation may still be preview-only or unavailable in your account, region, or gateway allowlist.

Step 4: Send a Chat Completions request with curl

curl --fail-with-body -sS "${BASE_URL}/v1/chat/completions" \
  -H "Authorization: Bearer ${PAT}" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "X-Snowflake-Request-ID: getting-started-openai" \
  -d "{\
    \"model\": \"${MODEL}\",\
    \"max_completion_tokens\": 64,\
    \"messages\": [\
      {\"role\": \"user\", \"content\": \"How does a snowflake get its unique pattern?\"}\
    ]\
  }"

The response follows the Chat Completions shape. Exact response fields can vary by model family.

Step 5: Point the OpenAI Python SDK at the gateway

The OpenAI-compatible SDK can use the same gateway by changing its base URL. The SDK's base_url includes /v1; the environment variable doesn't.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["PAT"],
    base_url=f'{os.environ["BASE_URL"]}/v1',
)

response = client.chat.completions.create(
    model=os.environ["MODEL"],
    max_completion_tokens=64,
    messages=[
        {"role": "user", "content": "How does a snowflake get its unique pattern?"}
    ],
)

print(response.choices[0].message.content)

Step 6: Call Claude models with the Anthropic Messages API

Use /v1/messages for the Anthropic-compatible API. The Messages API supports Claude models only.

curl --fail-with-body -sS "${BASE_URL}/v1/messages" \
  -H "Authorization: Bearer ${PAT}" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "X-Snowflake-Request-ID: getting-started-anthropic" \
  -d "{\
    \"model\": \"${CLAUDE_MODEL}\",\
    \"max_tokens\": 64,\
    \"messages\": [\
      {\"role\": \"user\", \"content\": \"How does a snowflake get its unique pattern?\"}\
    ]\
  }"

Step 7: Send a Bearer token from the Anthropic Python SDK

The Anthropic SDK normally uses x-api-key. Override that behavior so the request sends Snowflake's required Bearer token. Set the Anthropic SDK’s base_url to BASE_URL exactly as returned by SHOW AI GATEWAYS. Calling client.messages.create(...) adds /v1/messages automatically.

import os
import anthropic
import httpx

pat = os.environ["PAT"]
http_client = httpx.Client(
    headers={
        "Authorization": f"Bearer {pat}"
    }
)

client = anthropic.Anthropic(
    api_key="not-used",
    base_url=f'{os.environ["BASE_URL"]}',
    http_client=http_client,
    default_headers={
        "Authorization": f"Bearer {pat}"
    },
)

response = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[
        {"role": "user", "content": "How does a snowflake get its unique pattern?"}
    ],
)

print(response.content[0].text)

Step 8: Stream responses with server-sent events

Both provider-compatible APIs support server-sent event streaming. Set "stream": true in the request and use Accept: text/event-stream. Chat Completions streams end with data: [DONE]; production clients should handle incomplete streams, connection errors, and retryable responses.

curl --fail-with-body -sS "${BASE_URL}/v1/chat/completions" \
  -H "Authorization: Bearer ${PAT}" \
  -H "Content-Type: application/json" \
  -H "Accept: text/event-stream" \
  -H "X-Snowflake-Request-ID: getting-started-stream" \
  -d "{\
    \"model\": \"${MODEL}\",\
    \"max_completion_tokens\": 64,\
    \"stream\": true,\
    \"messages\": [\
      {\"role\": \"user\", \"content\": \"Count to 5.\"}\
    ]\
  }"

Production checklist for a governed inference endpoint

  • Use a dedicated service identity and a least-privileged inference role.
  • Discover BASE_URL with SHOW AI GATEWAYS; never hand-build the gateway URL.
  • Keep /v1 out of BASE_URL. Add it to the OpenAI SDK's base_url and curl request paths, but not to the Anthropic SDK's base_url.
  • Select model IDs from the gateway's current specification.
  • Keep gateway logging on and payload capture off until data handling is approved.
  • Keep gateway modification, monitoring, and quota-creation responsibilities separate.
  • Add X-Snowflake-Request-ID to requests and service.name to client telemetry.
  • Start with a small credit-based test quota, then validate propagation and enforcement.
  • Review the Cortex Inference and AI Observability with Snowflake Cortex before production rollout.

What's next: administering the gateway in Part 2

You now have the examples to call Cortex AI Gateway with familiar OpenAI and Anthropic clients, including streaming responses. In Part 2, we’ll move to the admin side: configuring the gateway specification, observing traffic, and setting a small test quota.

Updated Nov 3, 2026

This content is provided as is, and is not maintained on an ongoing basis. It may be out of date with current Snowflake instances