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.
  • 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).

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 →
  • 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 →

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.