TSAPI(3ts)

✨ TSAPI 💅 — the Apache Traffic Server API, explained by your fave unix girlie

okay so. welcome to the Apache Traffic Server API page, section 3ts of the manual. this is the doorway bestie. this is where you find out how to write plugins in C that make your Traffic Server install do exactly what you want it to do. grab a snack 🍓, we're going in.

---

🌸 SYNOPSIS 🌸

#include <ts/ts.h>
#include <ts/remap.h>

that's it. two includes and you're in. slay.

---

🦋 DESCRIPTION 🦋

The Apache Traffic Server API is literally your key to writing plugins — in the C programming language — that customize how your Traffic Server installation behaves. no cap.

Traffic Server handles sophisticated caching and processing of web-related traffic, like DNS and HTTP requests and responses. and the whole thing? it's an event-driven loop. boiled all the way down, it's giving:

for (;;) {
    event = get_next_event();
    handle_event (event);
}

iconic. that's the whole vibe. it just keeps pulling events and handling them, forever, bestie 💀

so here's the deal: you compile your plugin source code into a shared library, and Traffic Server loads it when it starts up. your plugin is full of callback functions that get registered for specific Traffic Server events. and when Traffic Server needs to process one of those events, it invokes any and all callback functions you registered for that event type. all of them. every single one. 🫶

💖 what even can plugins do tho

possible uses include, and I quote my own heart:

• HTTP processing plugins can filter, denylist, authorize users, or transform content.
• Protocol plugins can enable Traffic Server to proxy-cache new protocol content.
• A denylisting plugin denies attempts to access web sites that are off-limits.
• Append transform plugins add data to HTTP response content.
• An image conversion plugin transforms JPEG images to GIF images.
• Compression plugins send response content to a compression server that compresses the data — alternatively, a compression library local to the Traffic Server host machine could do the compression. either way, compressed ✨
• Authorization plugins check a user's permissions to access particular web sites. the plugin could consult a local authorization program, or send queries to an authorization server. choose your own adventure.
• A plugin that gathers client information from request headers and enters this information in a database. (data girlies rise up 📊)
• A protocol plugin listens for specific protocol requests on a designated port and then uses Traffic Server's proxy server and cache to serve client requests. main character energy fr fr.

---

👑 NAMING CONVENTIONS 👑

the Traffic Server API is so consistent about this, and honestly? we love that for us. here's the tea:

• The TS prefix is used for all function and variable names defined in the Traffic Server API. for example, TS_EVENT_NONE, TSMutex, and TSContCreate().
• Enumerated values are always written in ALL UPPERCASE LETTERS. for example, TS_EVENT_NONE and TS_VC_CLOSE_ABORT.
• Constant values are all uppercase; enumerated values can be seen as a subset of constants. for example, TS_URL_SCHEME_FILE and TS_MIME_FIELD_ACCEPT.
• The names of defined types are mixed-case. for example, TSHttpSsn and TSHttpTxn(). TSDebug()
• Function names are mixed-case too. for example, TSUrlCreate() and TSContDestroy().
• Function names use the following subject-verb naming style: TS-<subject>-<verb>, where <subject> goes from general to specific. this makes it easier to determine what a function does just by reading its name. for example, the function to retrieve the password field (the specific subject) from a URL (the general subject) is TSUrlPasswordGet().
• Common verbs like Create, Destroy, Get, Set, Copy, Find, Retrieve, Insert, Remove, and Delete are used only when appropriate. no filler verbs. periodt.

---

🎀 PLUGIN LOADING AND CONFIGURATION 🎀

when Traffic Server is first started, it consults the plugin.config file to figure out the names of all the shared plugin libraries that need to be loaded. plugin.config also defines the arguments that get passed to each plugin's initialization function, TSPluginInit(). meanwhile, the records.config file defines the path to each plugin shared library. two files, two jobs, both serving 💅

here's a sample plugin.config — it's got a comment line, a blank line, and two plugin configurations:

# This is a comment line.
my-plugin.so www.junk.com www.trash.com www.garbage.com
some-plugin.so arg1 arg2 $proxy.config.http.cache.on

each plugin configuration in plugin.config resembles a UNIX or DOS shell command. also important: each line in plugin.config cannot exceed 1023 characters. that's the limit bestie, don't test it.

so the first plugin configuration is for a plugin named my-plugin.so. it contains three arguments that are passed to that plugin's initialization routine. the second configuration is for a plugin named some-plugin.so, and it also contains three arguments. the last argument, $proxy.config.http.cache.on, is actually a configuration variable. Traffic Server will look up the specified configuration variable and substitute its value. cute, right? variable substitution but make it server config 🌈

and plugins get loaded and initialized by Traffic Server in the order they appear in the plugin.config file. order matters. iykyk.

---

💜 PLUGIN INITIALIZATION 💜

every plugin must define an initialization function named TSPluginInit() that Traffic Server invokes when the plugin is loaded. you literally cannot skip this one. TSPluginInit() is commonly used to read configuration information and register hooks for event notification. it's the glow-up moment where your plugin wakes up and says "hi, i'm here, and here's what i care about" ✨

---

🧚 FILES 🧚

• plugin.config
• records.config

---

⭐ SEE ALSO ⭐

• TSPluginInit(3ts)

---

🍓 COPYRIGHT 🍓

2026, dev@trafficserver.apache.org

---

okay that's the whole page bestie, you ate it, go write a plugin 💖 and for the record: this was Apache Traffic Server docs, version 9.2, dated Feb 12, 2026. mwah. 🫶✨