Integrations

Custom & Cloud-Hosted Agents

Redirect your agent's base URL to Spineforge and present a gateway key: you instantly get control and tracking, wherever the agent runs.


Agents you build yourself, and agents that run on someone else's infrastructure, make the same kind of call: an OpenAI-compatible request to a base URL, authenticated with an API key. Change those two values and the agent is governed.

1

Base URL: point your agent at the Spineforge gateway

https://spineforge-backend.onrender.com/gateway/v1
2

API key: use your Spineforge gateway key

sfgw-xxxx-xxxx
Prerequisite: add your provider key to the Spineforge Dashboard Vault and create a gateway key (sfgw-...) in the API Keys tab.

Python (OpenAI SDK)

from openai import OpenAI

client = OpenAI(
    base_url="https://spineforge-backend.onrender.com/gateway/v1",
    api_key="sfgw-xxxx-xxxx"  # Your Spineforge gateway key
)

resp = client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Summarise today's tickets."}],
)
print(resp.choices[0].message.content)

Node.js / TypeScript (OpenAI SDK)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://spineforge-backend.onrender.com/gateway/v1",
  apiKey: "sfgw-xxxx-xxxx", // Your Spineforge gateway key
});

const resp = await client.chat.completions.create({
  model: "openai/gpt-4o",
  messages: [{ role: "user", content: "Summarise today's tickets." }],
});
console.log(resp.choices[0].message.content);

LangChain

LangChain's OpenAI chat model accepts a base URL and key, so existing chains and agents work unchanged:

# Python
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    base_url="https://spineforge-backend.onrender.com/gateway/v1",
    api_key="sfgw-xxxx-xxxx",
    model="openai/gpt-4o",
)

# TypeScript
import { ChatOpenAI } from "@langchain/openai";

const llm = new ChatOpenAI({
  model: "openai/gpt-4o",
  apiKey: "sfgw-xxxx-xxxx",
  configuration: { baseURL: "https://spineforge-backend.onrender.com/gateway/v1" },
});

The same pattern applies to any framework built on an OpenAI-compatible client: find where it takes a base URL and API key and set them to the gateway values.

No code change: environment variables

The official OpenAI SDKs read OPENAI_BASE_URL and OPENAI_API_KEY from the environment, so you can often govern an existing agent without touching its code:

OPENAI_BASE_URL=https://spineforge-backend.onrender.com/gateway/v1
OPENAI_API_KEY=sfgw-xxxx-xxxx

Raw HTTP

curl https://spineforge-backend.onrender.com/gateway/v1/chat/completions \
  -H "Authorization: Bearer sfgw-xxxx-xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o",
    "stream": true,
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Visual builders (Flowise, Langflow and similar)

Low-code tools usually have an OpenAI Compatible or Custom OpenAI node. Set its Base URL (sometimes labelled Base Path or API Base) to the gateway URL, use your gateway key as the API key credential, and enter a provider-prefixed model name. Exact field names differ by tool and version.

Cloud-hosted agents

If an agent runs in a container, a managed platform, a serverless function or a CI job, the integration is still just configuration: inject the two values as environment variables. No SDK, no redeploy of your code logic.

Docker

docker run \
  -e OPENAI_BASE_URL="https://spineforge-backend.onrender.com/gateway/v1" \
  -e OPENAI_API_KEY="sfgw-xxxx-xxxx" \
  my-agent:latest

Kubernetes

apiVersion: v1
kind: Secret
metadata:
  name: spineforge-gateway
stringData:
  OPENAI_API_KEY: sfgw-xxxx-xxxx
---
# In your Deployment's container spec:
env:
  - name: OPENAI_BASE_URL
    value: https://spineforge-backend.onrender.com/gateway/v1
  - name: OPENAI_API_KEY
    valueFrom:
      secretKeyRef:
        name: spineforge-gateway
        key: OPENAI_API_KEY

Serverless, PaaS & CI

Add OPENAI_BASE_URL and OPENAI_API_KEY to your platform's environment-variable or secrets settings (for example in your function configuration, PaaS dashboard, or CI secret store) and redeploy the configuration. Use a separate gateway key per environment (production, staging, CI) so each is attributed and revocable on its own.

Third-party hosted agents

If a hosted agent product lets you bring your own OpenAI-compatible endpoint, enter the gateway URL and your gateway key there. If it only supports a fixed vendor endpoint, it can't be routed through the gateway.

Best practices

  • One gateway key per agent and environment. This is what makes cost attribution, budgets and revocation meaningful.
  • Scope the key. Restrict it to the providers and models the agent actually needs: see Scopes.
  • Set a budget cap and a rate limit so a runaway loop can't burn through tokens.
  • Store the key in a secret manager: not in source control or images.
  • Streaming and tool calling use the standard OpenAI-compatible request format and are passed through.

Troubleshooting

SymptomLikely cause
401 / invalid API keyThe key isn't a valid gateway key (must start with sfgw-) or contains stray whitespace.
403 / forbiddenThe key was revoked, or its scopes don't permit the requested provider or model.
Request blocked before reaching the providerThe agent hit its budget cap or rate limit. Check Governance & Scopes in the dashboard.
Model not found / routing errorMissing provider prefix on a model name that contains a slash. See Model Naming.
Provider authentication errorNo matching provider key in the Vault. Add it in the dashboard.
Connection refused / timeoutThe agent can't reach the gateway URL. Check egress rules and the Base URL (include /gateway/v1).

Next steps