Unified.to
All articles

How to Get a Grok / Groq (xAI) API Key — and Connect It to Your Product


February 20, 2026

Grok (Groq) is xAI's family of LLMs. To use it in an application, you'll first generate an xAI API key, then decide how you want to run it:

  • Call Grok directly via xAI's API
  • Or call Grok through a unified Generative AI API (so you can support multiple model providers without maintaining separate integrations)
  • Or connect Grok to your customers' SaaS platforms through MCP, so the model can perform authorized reads and writes

This guide covers the key setup steps, then shows the Unified path: GenAI API + MCP server.

Prerequisites

  • Active X Premium or X Premium+ subscription (required for Grok API access)
  • API access may take 24–48 hours to activate after subscribing

Step 1: Sign in to the xAI Console

  1. Go to:
https://console.x.ai
  1. Sign in with your X credentials

If it's your first time, complete onboarding (developer info, use case, terms).

Step 2: Create an API key

  1. In the xAI console, open API Keys
  2. Click Create API key
  3. Name it (e.g., prod-grok, dev-grok)
  4. Select permissions and model access
  5. Create the key

Your API key is shown once. Store it securely (environment variable, vault).

Step 3: Configure billing and rate limits

In the console, configure:

  • Usage caps (daily/monthly)
  • Alert thresholds
  • Overage behavior

Then confirm your current rate limits and quotas for your plan.

Step 4: Test the Grok API key

Example request:

curl https://api.x.ai/v1/chat/completions \
  -H "Authorization: Bearer $GROK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-1",
    "messages": [
      { "role": "user", "content": "What is happening on X today?" }
    ],
    "temperature": 0.7,
    "stream": false
  }'

If successful, you'll get a JSON response with the model output.

Option A: Call Grok through Unified's Generative AI API

If you're building an AI product, Grok is rarely your only model provider long term.

Most teams end up supporting multiple providers for:

  • fallback when a provider is down
  • cost/performance tradeoffs
  • embedding portability
  • customer preference (enterprise procurement often drives this)

Unified's Generative AI API gives you a standardized interface across supported LLM providers (including Grok), with consistent objects for Models, Prompts, and Embeddings.

What you build against

Conceptually, the GenAI API is three core objects:

  • Model (capabilities like max tokens, temperature support)
  • Prompt (messages, temperature/max_tokens, responses/tokens_used)
  • Embedding (content, dimensions, embeddings array, tokens_used)

This is the 'build once' path for GenAI providers (not just Grok).

Common GenAI product patterns this unlocks

  • Run the same prompt across providers to compare responses
  • Route requests across providers based on availability/config
  • Generate embeddings across providers for RAG and semantic search
  • Keep your app code stable while swapping model providers underneath

(Keep the provider-specific key management where it belongs: auth + secret storage, not in your business logic.)

Option B: Use Grok as the 'brain,' Unified MCP as the action layer

LLM calls are only one piece.

The harder part is letting the model take action against customer SaaS tools safely:

  • list candidates from an ATS
  • update a CRM deal
  • fetch a file from Google Drive
  • write a comment into HubSpot

Unified's MCP server connects any Unified connection to LLM providers and clients that support MCP (Claude, OpenAI, Gemini, Cohere, Grok, Groq, Cursor, etc.). The tools available depend on the integration's support and the connection's requested permissions.

MCP URLs (regional)

  • Streamable HTTP:
    • https://mcp-api.unified.to/mcp
    • https://mcp-api-eu.unified.to/mcp

(You can keep traffic regionalized; Unified is designed as a pass-through, zero-storage platform.)

Tool limits are real

Most LLMs cap how many tools they can reliably handle. The practical implication: you must restrict tool scope using permissions and tool filters, or you'll hit model limits fast.

Unified supports scoping with:

  • permissions
  • tools
  • defer_tools (for lowering tool token usage)
  • include_external_tools=true (when you explicitly want broader endpoint coverage)

Using Grok tool-calling with Unified MCP

Grok supports tool calling in a pattern similar to other tool-based LLM APIs.

High-level flow:

  1. Fetch tools in Grok's expected format:
GET /tools?type=grok
  1. Send those tools to Grok's chat completion call (tool_choice: "auto")
  2. When Grok returns tool_calls, call Unified:
POST /tools/{tool_id}/call
  1. Return the tool results back to Grok as role: "tool" messages

This keeps the LLM's role clear:

  • Grok decides what to do next
  • Unified executes the authorized tool call against the underlying platform API
  • Your app owns the product logic around approvals, UI, audit, and retries

MCP safety controls you should use

When you ship this in a product, the defaults matter.

Unified MCP supports controls like:

  • hide_sensitive=true to reduce PII in tool results (names, emails, phone numbers, etc.)
  • permissions=... to restrict what the connection is allowed to do
  • tools=... to limit the tool set the model can access

This is how you keep tool calling usable, auditable, and constrained.

Key takeaway

If all you need is an LLM response, calling Grok directly is fine.

If you're building an AI product that needs:

  • multiple model providers (fallback, routing, comparison, embeddings)
  • and real SaaS actions (read/write) across customer integrations

…then the clean architecture is:

  • Unified Generative AI API for model access across providers
  • Unified MCP server for authorized tool calling into customer integrations
  • Your app for product logic and user experience

That's the difference between 'LLM demo' and 'AI feature shipped.'

→ Start your 30-day free trial

→ Book a demo

All articles