Personalization as a live API endpoint

A personalization endpoint is a live API you call with a key, a user, a piece of content, or any identifier you choose, and it returns personalized JSON ready to drop straight into an email, a push, or an in-app surface. Every personalization TrailGuide can produce is reachable this way, as an endpoint you can hit on demand.

This is the difference between personalization that stays trapped inside one channel and personalization you can put anywhere. If a recommendation, a ranked list, or a tailored message can be requested over HTTP and returned as clean JSON, then any surface you own can show it, not only the ones the platform happens to ship with.

One key in, personalized JSON out

The contract is deliberately simple: you pass a key and get back JSON. The key can be a user ID when the personalization is about a person, a content ID when it is about a thing, or an arbitrary value when you have your own notion of what to personalize on. The response is structured data, not rendered HTML, so your email template, push payload, or in-app component stays in full control of how it looks.

Keeping the response as data is what makes an endpoint reusable. The same call can feed a subject line in one place and a card in another, because the endpoint decides what to say and the surface decides how to show it.

It also means personalization is not locked to TrailGuide surfaces. A custom app screen, a server-rendered page, or a partner integration can all call the same endpoint and get the same tailored result, because the doorway is a plain API rather than a proprietary widget.

One-to-one or content-keyed

Endpoints come in two shapes. A one-to-one endpoint is keyed on a single user: pass the user, get back what to say or show to that person. A content-keyed endpoint is keyed on an item, a recipe, a product, or a book, and returns the personalization for that item, such as who it suits and how to pitch it.

For Shelf, a book-tracking app, a content-keyed endpoint might take a book ID and return a tailored blurb along with the readers it fits. For Cadence, a fitness app, a one-to-one endpoint might take a user ID and return the next workout worth surfacing. Same contract, two natural ways to key it, depending on whether the subject is a person or a thing.

Preview before you wire it up

Every endpoint has a live preview. You can run it against real users to see exactly what they would receive, or against arbitrary key/value pairs to test cases you construct by hand. You see the real response shape before writing a line of integration code, so there are no surprises when the endpoint reaches a production template.

Snippets for every stack

To close the gap between "the endpoint works" and "it is in my app", TrailGuide generates ready-to-paste snippets for every endpoint in cURL, JavaScript, Python, and Node. Whoever wires it up gets a working call in the language they are already writing, so integration is copy, paste, and adjust rather than read the reference and build from scratch.

The snippets are generated per endpoint, not copied from a generic template, so the URL, the parameters, and the auth are already filled in for the exact endpoint you are looking at. There is very little left to get wrong.

curl -s https://api.trailguide.co/p/next-workout \
  -H "Authorization: Bearer $TRAILGUIDE_KEY" \
  -d "user_id=u_10472"

Low-latency and cached

Because endpoints get called on the hot path of an email render or an app screen, responses are low-latency and cached. A surface can request personalization inline without paying a slow round trip, and repeated calls for the same key are served quickly. Personalization that is fast enough to call at render time is personalization you can actually use everywhere.

Underneath, the copy an endpoint returns stays inside your guardrails, and the data it personalizes on comes from whatever sources you connected. The endpoint is just the doorway; behind it is the same governed content and the same warehouse the rest of the harness runs on.