--- title: "Provider Integrations" description: "OpenAI, Anthropic, Voyage AI, Azure. Add providers, set credentials, bind deployments." canonical: https://www.norcaster.com/docs/providers --- # Provider Integrations Norcaster integrates with major cloud model APIs—plus a built-in demo model for first success without keys. Providers are org-scoped; credentials are encrypted at rest. What is supported today - **OpenAI** and **Anthropic** — typical chat workloads; sync models after saving your API key. - **Azure OpenAI**, **AWS Bedrock**, **Groq**, **Together AI** — connect per your cloud setup; capabilities depend on the model you enable. - **Voyage AI** — primarily embeddings for knowledge bases and document pipelines. - **NVIDIA NIM** — register a customer-hosted NIM (OpenAI-compatible) as a first-class provider. Private-range base URLs are allowed on self-hosted and hybrid data plane installs only. An NGC API key is for pulling containers, not for calling the NIM. - **Mistral** — La Plateforme (api.mistral.ai) as a first-class provider, OpenAI wire for chat, streaming and embeddings. Mistral states that La Plateforme hosts and processes in the EU by default; Norcaster records the provider's residency as `eu` on that basis — declared by the provider, not measured by Norcaster. A custom base URL (self-hosted vLLM, marketplace) is honoured; re-check the residency tag when you set one. - **Google Gemini** — the Gemini Developer API (generativelanguage.googleapis.com) on the OpenAI wire for chat, streaming and embeddings. The Developer API exposes no region, so a residency tag on this provider stays declared and is never reported as verified. **Vertex AI is a separate surface and is not supported yet** — it needs short-lived Google credentials rather than a stored key. - **Google Vertex AI** — the same OpenAI wire, on self-hosted installs only. Vertex authenticates with the Google credentials of the install itself, so there is no key to set and none is stored. Set the project and the region; the region is part of the endpoint, so a residency tag on a Vertex provider is checked against where requests actually go instead of being taken on trust. The managed cloud cannot offer this yet — it has no per-organisation Google identity to use. - **qx-example / orchestrator** — demo and test path when you do not want an external provider yet. The self-hosted *model runtime* is the customer's NIM or vLLM, not Norcaster's demo container. ## Portal **Dashboard → Providers** — Add Provider, choose type (Voyage AI, OpenAI, Anthropic, etc.), set credential (API key), Sync Models. Then bind a deployment to a provider model via the deployment detail page (Inference target). ## Setup 1. Create an org (if needed) 2. Add Provider → choose type (e.g. Voyage AI for embeddings) 3. Set Credential → paste API key 4. Sync Models → pick models (chat, embeddings, etc.) 5. Create a deployment, then bind it to a provider model in the deployment detail ## Provider notes ### Anthropic Commonly used for Claude chat workflows and DPA-safe ticket analysis demos. ### OpenAI Commonly used for chat and general model inference workloads. ### Azure OpenAI Useful when your organization already governs OpenAI access through Azure. ### AWS Bedrock Use when your model access and compliance controls are centered in AWS. ### Groq / Together OpenAI-compatible chat providers. Native tool calling depends on the selected model. ### Voyage AI Primarily used for embeddings in knowledge and retrieval pipelines. ### Mistral La Plateforme via the OpenAI wire (chat, streaming, embeddings). Residency recorded as eu on Mistral's published default (provider statement); the tag is declared, not verified. Model list from GET /v1/models with a curated fallback (mistral-large/medium/small-latest, codestral-latest, mistral-embed). ### Google Gemini Gemini Developer API via the OpenAI wire (chat, streaming, embeddings), base URL https://generativelanguage.googleapis.com/v1beta/openai/ with your Gemini API key. Model list from GET /models with a curated fallback; image, TTS, Live and transcription models are filtered out because they are not servable on the chat/embeddings wire. Residency is not derivable for this provider — the endpoint carries no region — so a tag you set reads as declared, not verified. Vertex AI is not supported yet. ### Google Vertex AI OpenAI wire on self-hosted installs only. Authenticates from the install's own Google credentials (Application Default Credentials) — no key is stored, and the bearer token is minted per request and refreshed before it expires. Config is the Google Cloud project and the region; the global location is not supported. Residency derives from the region in the endpoint, so a declared tag reads as verified or as a contradiction rather than merely declared. Managed-cloud and hybrid tenants need per-organisation workload identity federation, which is not available yet. ### NVIDIA NIM Customer-hosted OpenAI-compatible NIM. Readiness is GET /v1/health/ready; models from GET /v1/models. Runtime identity (engine, image digest, NIM version) is recorded when the NIM reports it — otherwise null + not\_reported. Verified against nvcr.io/nim/meta/llama-3.2-3b-instruct:1.10.1 on a rented NVIDIA A10 on 2026-09-09. Not an NVIDIA partnership, validation, or listing. ### Provider-backed deployments Workflow model and agent nodes run through provider-backed inference targets bound to deployments. ## Use cases - **Chat inference** — Bind deployment to OpenAI/Anthropic for inference - **Embeddings** — Voyage AI for embeddings (powers knowledge bases and document lookup) - **Document Q&A** — Embedding provider + knowledge base for retrieval (often called RAG) - **Multi-model workflows** — Bind different model nodes to different provider-backed deployments in one workflow. [Read the multi-model workflow guide →](https://www.norcaster.com/docs/multi-model-agents) - **Native agents** — Use provider-backed chat models with native tool calls. Norcaster normalizes tool calls across Anthropic and OpenAI-compatible providers, but actual support still depends on the provider and model you select. ## NVIDIA NIM — what is recorded Norcaster is not NVIDIA-validated, partnered, or listed. When a customer runs NIM on their own GPUs, register type `nvidia_nim` with the NIM origin as `config.base_url`. Verified against `nvcr.io/nim/meta/llama-3.2-3b-instruct:1.10.1` on a rented NVIDIA A10 on 2026-09-09. - **Readiness** — `GET /v1/health/ready` (200 = valid). Liveness `GET /v1/health/live` is not used for validation. - **Model sync** — `GET /v1/models`. Capabilities are chat unless the endpoint reports embeddings. The 1.10.1 chat NIM had no `capabilities` field. Model-name guessing is not used. - **Runtime identity** — per request: `provider_type`, `model_id`, `served_model_name`, `engine`, `image_digest`, `runtime_version`, `source`. `source` is one of `response_header`, `metadata_endpoint`, `operator_annotation`, or `not_reported`. On the 1.10.1 chat NIM, `GET /v1/metadata` returned 200 with `version.release` and `modelInfo[0].shortName`; it did not report engine or image digest, and responses had no `x-nim-*` headers. Set `config.runtime_annotation.image_digest` from `docker inspect` / the pod `imageID` when you need the digest. Fields the NIM does not report stay `null`. - **Operator annotation** — optional `config.runtime_annotation` when the NIM reports nothing. Recorded with `source: operator_annotation`. - **GPU seconds** — not present on the chat response. On this 1.10.1 image, `GET /metrics` returned 404, so GPU seconds stay `not_reported` until an operator Prometheus scrape is wired. Optional `prometheus_url` + operator-supplied `gpu_seconds_query` (no default query is shipped). Apportioned by token share; tagged `gpu_attribution: apportioned_by_tokens`. - **Embeddings** — a chat NIM returns HTTP 404 on `/v1/embeddings`. That is a clear error; it does not mark the provider unhealthy. ## Using provider models with MCP data If your workflow fetches context from an MCP server and then calls a provider model (for example Anthropic), use a stable `result_field` and route redaction plus model prompting through the text field that exists after redaction. Norcaster normalizes MCP tool output so custom payload shapes still work. [Read the workflows + MCP contract guide →](https://www.norcaster.com/docs/workflows) ## Credentials and data flow Provider credentials are org-scoped and encrypted at rest. Norcaster uses them server-side to call the selected provider model through an inference target. What the provider receives depends on the deployment, workflow, policies, and redaction steps configured before the model call. For audit proof, inspect the model node output and the Analyze page's “What reached Claude” section. It shows provider/model metadata and the payload sent to the provider.