Capstone Project: Loyalty Points API

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Build a complete Loyalty Points API for Brew & Bytes: validated, retry-safe, authorized, versioned, documented and monitored.

A capstone project brings together everything you learned throughout the course and applies it to a real API feature.

In this lesson, you will build the Brew & Bytes Loyalty Points API.

Customers earn points when they make purchases and redeem those points later for rewards. Along the way, you will apply concepts such as API design, validation, authentication, authorization, versioning, caching, monitoring, rate limiting, testing, and documentation.

This is not a new topic. It is a practical application of all the topics you have already learned.

Watch a Quick Loyalty API Go Wrong

The marketing team wanted a loyalty program delivered quickly. An API was written in a hurry. Press Run.

Several serious problems appear immediately:

Duplicate Points

Order 101 is submitted twice because the app retries the request.

The server awards: 44 points

twice.

The customer receives double rewards.

Free Points

A request claims an order amount of: ₹100000

The server trusts the value and awards: 10000 points

even though no such payment exists.

Missing Authorization

The client provides any: customerId it wants.

Anyone can:

• Earn points for another account
• Read another customer's balance
• Spend another customer's points

The API technically works, but it trusts data that should never be trusted.

In simple words: every important security, validation, and ownership rule is missing.

TL;DR

• Design resources, requests, responses, and status codes before writing code.
• Validate all incoming data.
• Take customer identity from the token, not from the request body.
• Require Idempotency-Key for write operations.
• Check authorization on every request.
• Return 404 for balances that belong to someone else.
• Return 409 Conflict when business rules prevent an action.
• Add breaking changes in new API versions.
• Document the API with OpenAPI.
• Include a correlation id in responses and logs.

A Real-World Example

Think about a real loyalty card program in a coffee shop.

The business defines rules such as: 1 point for every ₹10 spent

The cashier:

• Verifies the customer.
• Awards points once per purchase.
• Records every transaction.
• Prevents spending more points than available.
• Explains how a balance was calculated.

Later, the business introduces: Bronze, Silver and Gold tiers.

Existing cards continue to work while new features are added.

A production loyalty API follows the same principles.

What You Will Learn

In this lesson, you will:

1. Design a loyalty API contract.
2. Validate requests properly.
3. Take ownership information from tokens.
4. Make writes retry-safe.
5. Enforce authorization rules.
6. Introduce API versioning.
7. Document the API.
8. Monitor and test the completed solution.

Step 1: Design and Validate

The first endpoint is:

POST /v1/loyalty/earn

Purpose:

Add loyalty points after a purchase

The endpoint requires:

• Authentication
• Input validation
• Correct status codes

No Token

Response:

401 Unauthorized

Authentication is required.

Invalid Amount

Request:

{
  "amount": 0
}

Response:

400 Bad Request

with:

{
  "errors": {
    "amount": [...]
  }
}

Fake Customer ID

Request:

{
  "customerId": "customer-7"
}

Token:

customer-8

Result:

Points are awarded to:

customer-8

The body value is ignored.

Valid Request

Request:

{
  "amount": 120
}

Response:

201 Created

Points earned:

12

using:

1 point per ₹10 spent

Step 2: Make Writes Safe and Secure

The next goal is to prevent duplicate points and unauthorized access.

Prevent Duplicate Points

The first request earns: 44 points

A retry sends the same:

Idempotency-Key

Instead of processing the request again, the server returns the original result.

Balance remains: 44 points and not 88 points

Require an Idempotency Key

Missing key:

400 Bad Request

Without a key, the API cannot distinguish:

• A retry
• A brand-new request

Protect Customer Balances

Ravi attempts to:

• Read Asha's balance
• Redeem Asha's points

Both requests receive:

404 Not Found

No balance information is revealed.

Prevent Overspending

Asha has: 44 points

She attempts to spend: 100 points

Response:

409 Conflict

The business rule prevents the operation.

Valid Redemption

Spend: 30 points

Result: 44 → 14 points

Balance updates successfully.

Step 3: Version and Document the API

The business wants loyalty tiers: Bronze, Silver and Gold

Existing clients already use:

/v1/loyalty/me

Changing the response directly would break those clients.

Instead, create a new version.

Version 1

Response:

{
  "points": 240
}

Existing applications continue to work.

Version 2

Response:

{
  "points": 240,
  "tier": "silver"
}

New clients gain access to the additional feature.

OpenAPI Documentation

Endpoint:

/openapi/v1.json

Documents:

• Routes
• Request bodies
• Response models
• Status codes
• Authentication requirements

Partners can integrate without needing manual instructions.

Step 4: Test Like a Real Client

Every important scenario should become an automated test.

The tests verify:

• Earn points successfully
• Retry with the same idempotency key
• Prevent duplicate points
• Reject insufficient balances
• Prevent access to another customer's data
• Return correct status codes
• Return correlation ids

Each response includes:

X-Correlation-Id

Support teams can use that identifier to locate the exact request in logs.

Architecture of the Finished Loyalty API

Client
   │
   ▼
Authentication
   │
   ▼
Authorization
   │
   ▼
Validation
   │
   ▼
Idempotency
   │
   ▼
Business Rules
   │
   ▼
Database
   │
   ▼
Logging & Monitoring

Each layer protects the system from a different type of failure.

Your Checklist

Take It Home

Download the finished API from the last box as a real project, and run it on your own computer. The C# zip is an ASP.NET Core 10 project. The TypeScript zip is a Node.js project with Hono. Both include the same requests as a .http file.

Where You See This

• Coffee shop loyalty systems
• Airline rewards programs
• E-commerce reward points
• Cashback and wallet systems
• Membership platforms
• Customer reward applications

These systems use the same principles:

• Authentication
• Authorization
• Validation
• Idempotency
• Monitoring
• Versioning
• Testing

Common mistakes

Exercises

What to Remember

• A good API is designed, validated, secured, versioned, documented and watched.
• Take the identity from the token. Check the owner on every request.
• Writes that move points or money must be safe to retry.
• Use 409 for clashes, and use Problem Details for every error.
• Add new things in a new version.

Next: API Cheat Sheet. Keep it open while you build your own APIs.