Y

Project · Beginner · about 12 hours

Sync support tickets into a helpdesk API with TypeScript

Write a typed, validated and tested TypeScript tool that loads customer messages into a helpdesk REST API without duplicates, even when the API fails halfway.

Skills:Git and GitHub, REST APIs and HTTP, TypeScript and JavaScript

Part of: Forward Deployed Engineer

Data and licences

Brief

A customer is moving to a new helpdesk and needs their message history loaded into it. The new helpdesk has a REST API that sometimes returns 429 or 503. Engineers who work with customers write this kind of tool all the time, often in TypeScript, and the difference between a good one and a bad one is what happens when it fails halfway.

What to build

  1. Write a mock helpdesk API with POST /tickets (accepts an Idempotency-Key header) and GET /tickets. Make 10% of requests fail with 503 and some with 429 and a Retry-After header.

  2. Export 1,000 Bitext rows to JSON Lines. Validate each row with a zod schema; write invalid rows to a rejects file with the reason.

  3. Send tickets with a concurrency limit. Retry 429 and 5xx with exponential backoff, respecting Retry-After; never retry 4xx validation errors.

  4. Use a stable idempotency key per row so re-running the sync after a crash creates no duplicates. Prove it with a test that kills the sync halfway.

  5. Print a summary: sent, skipped, rejected, retried.

Deliverables

  • Repository with mock-api/, sync/, tests/, strict tsconfig.json and README.md

How it is graded

Reviewers run the sync twice with failures turned up to 30% and count tickets in the mock API. Exactly 1,000 minus rejects is a pass.

Stretch

Add a --dry-run flag and a progress bar, and publish the tool as an npm package in a private registry or as a GitHub release.

Deliverables

  • A small mock helpdesk API (any framework) with create and list endpoints and random failures
  • A TypeScript sync tool with zod validation, retries with backoff and idempotency keys
  • Tests with node:test covering validation, retries and re-running the sync
  • A README with setup, usage and the design decisions

How a reviewer grades it

CriterionWeightWhat good looks like
Input rows and API responses are validated, with clear errors25%
Retries only transient failures, with backoff and a limit20%
Re-running the sync never creates duplicates30%
Tests, strict type checking and a clean README25%