Skip to main content
Using a coding agent? Load the together-chat-completions skill to teach your agent to write correct chat completions code for Together AI. Learn more.
This guide walks through building and deploying a single-turn chat API. You will create a small web service that accepts an authenticated POST /chat request, forwards the message to Together AI’s chat completions API, and returns the model’s reply as JSON. You can follow the guide in TypeScript with Express or in Python with FastAPI. Both versions call https://api.together.ai/v1/chat/completions, default to Qwen3.5 9B, expose an unauthenticated GET /health endpoint for Render health checks, protect POST /chat with a separate bearer token, and stop an inference request after 60 seconds.

Architecture

A trusted client sends an authenticated POST /chat request to the Render web service, which calls Together AI and returns the reply, model ID, and token usage. CHAT_API_KEY authenticates the caller on the first hop, and TOGETHER_API_KEY stays inside the service.
Each request follows four steps. The client sends a bearer token and a message to the Render service. The service validates both. The service sends one chat completion request to Together AI. The service returns the reply, model ID, and token usage to the client. The service uses two separate secrets. CHAT_API_KEY authenticates the caller, and TOGETHER_API_KEY authenticates the server-to-server request to Together AI.

Prerequisites

Before you start, make sure you have: You also need a secret that callers will use to authenticate with your chat API. Generate one and save it in a password manager:
Shell
This value becomes CHAT_API_KEY. It is different from your TOGETHER_API_KEY.
The shared CHAT_API_KEY is a minimal guard for a server-to-server demo. Do not embed it in browser or mobile application code. For a public application, add user authentication, per-user authorization, and rate limits.

Step 1: Create the project

Create a new directory and initialize a Git repository:
Shell
Create a subdirectory for the runtime you want to use. You only need the files for the path you select.
For the TypeScript path, create package.json:
ts/package.json
Then create tsconfig.json:
ts/tsconfig.json
Install the dependencies and compile the project:
Shell
Commit the generated ts/package-lock.json. The Render build uses npm ci, which requires this file. For the Python path, create requirements.txt instead:
python/requirements.txt
Verify the dependencies in an isolated environment:
Shell

Step 2: Add the chat handler

The handler validates the caller before it makes a billable request to Together AI. It also limits the message to 8,000 characters and maps upstream failures to explicit HTTP responses.
Check the finished code before you deploy it:

Step 3: Configure the Render service

Render can create the service from a Blueprint stored in render.yaml. Create that file in the repository root and use the version for your runtime.
Two Render settings matter here. The server binds to 0.0.0.0 so Render can route traffic to it, and it reads the PORT environment variable that Render provides. The sync: false setting tells Render to prompt for each secret during the initial Blueprint creation instead of storing it in Git. Render does not prompt for these values when it creates a Blueprint preview, so set preview secrets separately if you use preview environments.

Step 4: Deploy the Blueprint

Commit the project and push it to your Git provider:
Shell
Then create the service:
  1. Open the Render Dashboard.
  2. Select New, then Blueprint.
  3. Connect the repository.
  4. Enter your Together project API key for TOGETHER_API_KEY.
  5. Enter the secret you generated earlier for CHAT_API_KEY.
  6. Select Deploy Blueprint.
Render builds the selected runtime and assigns the service an HTTPS URL such as https://together-chat-xxxx.onrender.com. The service is ready when the deploy is live and the /health check passes.
A free Render web service spins down after 15 minutes without inbound traffic. Its next request can take about a minute while the service starts again. Use a paid instance if your application needs consistent response latency.

Step 5: Verify the deployment

Save the service URL in your shell:
Shell
Check the health endpoint:
Shell
The response includes the configured model:
Confirm that the chat route rejects an unauthenticated request:
Shell
The response has HTTP status 401. Next, load your CHAT_API_KEY without placing it in your shell history:
Shell
Send one authenticated inference request:
Shell
A successful response has this shape:
The exact reply and token counts vary.
A non-empty reply confirms that the client authentication, Render service, Together API key, model ID, and network path all work.
Remove the shared secret from your shell when you finish:
Shell

Change the model

The example uses Qwen3.5 9B. To use a different chat model:
  1. Choose a model from the recommended models or the serverless model catalog.
  2. Open the service in the Render Dashboard.
  3. Change TOGETHER_MODEL under Environment.
  4. Save the change and deploy the service.
  5. Repeat the authenticated verification request.
Model availability, capabilities, and pricing change over time. Check the live catalog before changing the model string.

Extend the app

This guide sends one user message and waits for one complete response. These features require changes to the request schema and the handler:
  • Multi-turn chat: Accept and validate a messages array instead of a single message. See chat completions.
  • Streaming: Request stream: true and forward the returned stream to the client. The client must also parse streamed events.
  • Structured JSON: Add a supported response format and schema. See structured outputs.
  • Public access: Replace the shared bearer token with user authentication, and add rate limiting, usage monitoring, and abuse controls.

Next steps

Chat completions

Add multi-turn conversations and streaming to the handler.

Structured outputs

Enforce a JSON Schema on the model response.

Render web services

Review instance types, health checks, and scaling on Render.

Batch inference

Process many independent requests offline at lower cost.