#Server Paths

Every Telepact server follows the same basic shape:

1. define a schema directory

2. load that schema with a Telepact runtime

3. route validated requests to function handlers

4. connect the runtime to a transport boundary

#Choose a runtime

Telepact currently ships server libraries for:

• TypeScript

• Python

• Java

• Go

Pick the runtime that fits the service you are already building. Telepact is transport-agnostic, so the same schema and server shape can sit behind HTTP, WebSockets, or another IPC boundary that moves bytes.

#Minimal server path

If you want the fastest path to a running server:

• follow the Quickstart

• continue with Learn by Example: Minimum server

• use the runtime README for your language

#Transport adapter path

Keep the transport adapter thin.

Its job is usually just:

• receive request bytes

• call server.process(...)

• send response bytes back through the transport

See the Transport Guide for concrete HTTP and WebSocket patterns.

#Middleware and auth path

Put request-level concerns near the Telepact runtime boundary:

• auth normalization

• request ids

• logging

• metrics

• other policy checks

Start here:

• Auth Guide

• Learn by Example: Auth

• Learn by Example: Server auth

• Learn by Example: Managed auth

• Operating Boundary Guide

#Operating boundary path

When placing Telepact inside a larger service, focus on:

• schema compatibility policy

• where auth and observability hooks attach

• transport responsibilities versus Telepact responsibilities

• exact runtime/tool versioning

Start here:

• Operating Boundary Guide

• Runtime Error Guide

• Versions