> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scrip.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Rewards infrastructure API backed by a double-entry ledger. Send events, define earn rules, and operate incentive programs without building the accounting.

Scrip is an API for building loyalty and rewards programs. You send events from your application, define rules that control when and how participants earn, and Scrip tracks every balance change in a double-entry ledger.

Most teams start loyalty programs with a few columns in their application database. That works until you need expiration, vesting, promotional windows, refund handling, hold/release flows, or an audit trail. At that point you're building something that looks a lot like a financial system.

Scrip gives you two building blocks for this:

* A **rules engine** that evaluates conditions against incoming events and participant state. Conditions are written in [CEL](/guides/cel-expressions) (Common Expression Language), a lightweight expression syntax. When they match, actions fire: credits, debits, holds, tags, counter increments, and more. Logic lives in configuration, not application code.
* A **double-entry ledger** that records every balance change as a journal entry. Every credit to a participant has a corresponding debit from a source (like a program wallet). Nothing is mutated in place, so you always have a complete audit trail.

## How it works

1. Your app sends an **event** (a purchase, a signup, a referral) with whatever data your rules need.
2. The engine evaluates every active **rule** in the program against the event and the participant's current state.
3. When a condition matches, the rule's **actions** fire: credit points, debit a balance, set a tag, increment a counter.
4. Every balance change is recorded in the **ledger** as an immutable journal entry.

Events process asynchronously. The API confirms receipt, and a worker handles evaluation and execution. Processing is idempotent: retrying the same event with the same `idempotency_key` produces the same result, so retries are always safe.

## Next Steps

<CardGroup cols={3}>
  <Card icon="rocket" href="/quickstart" title="Quickstart">
    Set up a program and process your first event.
  </Card>

  <Card icon="server" href="/guides/core-concepts" title="Core Concepts">
    Programs, assets, rules, and the ledger.
  </Card>

  <Card icon="book" href="/examples/common-patterns" title="Common Patterns">
    Copy-paste rule recipes for category multipliers, sign-up bonuses, streaks, referrals, and more.
  </Card>
</CardGroup>
