How Retidal works

The four-arc model — Reach, React, Reward, Return — and how the two APIs implement it.

Retidal runs on two public HTTP surfaces that together implement four arcs of a single value loop: capture, decide, reward, and account for it.

Prerequisites

A Retidal project and a project API key — see Quickstart.
The vocabulary in Core concepts — project, event, visitor.

The four arcs

Reach — attribution and acquisition: every visit and click is captured and attributed, so nothing you paid for is invisible. Ingested through POST /api/v1/t and short links (/s/{code}).
React — the decisioning engine: POST /api/v1/decide evaluates rules in real time and returns a decision for that visitor, without a deploy per rule change.
Reward — incentive execution: once a decision fires, coupons and loyalty mechanics are issued and redeemed (POST /api/v1/coupons/redeem).
Return — payback and metering: conversion (metering) events are recorded and returned to the channels and dashboards that need to know, closing the loop back to Reach.

What this unlocks

Understanding these four arcs unlocks reading every other Get started page as “which arc does this belong to”: Sending data and Attribution are Reach, Decisioning is React, Coupons is Reward, and metering events close Return.

Verify it worked

Confirm you can point at Reach’s ingestion endpoint and get an ingestion-shaped response, not a 404:

1
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://api.retidal.com/api/v1/t
2
# expect: 401 — no X-API-Key header, but a 401 is Reach's endpoint
3
# responding (the auth check runs before any not-found routing would apply)

If it doesn’t work

If none of the four arcs match what you’re trying to do, or a request behaves unexpectedly, work through the health checklist.