#Core Concepts
This page gives the shortest high-level map of Telepact's main ideas before you dive into the detailed guides.
#Message shape
Telepact messages are always two JSON objects in an array:
[headers, body]the first object holds headers
the second object holds one request or response payload
Requests usually look like:
[{}, {"fn.example": {"field": 1}}]Responses usually look like:
[{}, {"Ok_": {"field": 1}}]For a more complete walkthrough, start with the Quickstart or Learn Telepact by Example.
#Schema role
The Telepact schema is the contract that drives the whole ecosystem.
It defines:
function arguments and results
reusable structs and unions
shared errors and headers
what counts as valid requests and responses
That one schema also powers:
server-side validation
documentation rendering
mock servers
optional client code generation
compatibility checks
For the full language, see the Schema Writing Guide.
#Headers versus body
The body contains the main request or response payload.
Headers are separate metadata that travel alongside that payload. They are where Telepact puts cross-cutting concerns such as auth, request ids, binary negotiation, and select directives.
As a rule of thumb:
use the body for domain data and function arguments/results
use headers for metadata and transport-adjacent control signals
For more detail, see:
#Function links
Telepact functions can appear as data types inside other payloads. That lets a server return a pre-populated function call that a client can follow later.
This gives Telepact a hypermedia-like capability without requiring HTTP-specific link formats.
See:
#Select
Telepact supports response shaping through the @select_ header. Clients can ask for fewer fields from a response graph without inventing a separate query language.
See:
#Binary
Telepact can negotiate a compact binary representation at runtime. This means a client can keep a JSON-first development workflow and still upgrade to binary when it wants more efficiency.
See:
#Where to go next
If you are designing an API, go to the Schema Writing Guide.
If you are building a client, go to Client Paths.
If you are building a server, go to Server Paths.
If you want the CLI and related workflows, go to Tooling Workflow.