Build an OAuth-based data migration client

Prompt

Build a small command-line program that migrates records from a legacy HTTP API to a new HTTP API.

Required steps

1. Obtain an access token using OAuth 2.0 (Client Credentials flow).
2. Call the legacy endpoint using the token to fetch data.
3. Transform the data according to the rules below.
4. Send the transformed data to the new endpoint.
5. Compute and attach a checksum for each payload you send.

API contracts (assume these for the exercise)

1) Token endpoint

• POST https://auth.example.com/oauth/token
• Body (JSON):
  • client_id , client_secret , grant_type="client_credentials"
• Response (JSON):
  • access_token (string)
  • expires_in (seconds)

2) Legacy data endpoint

• GET https://legacy.example.com/v1/records?page=<n>&page_size=<k>
• Header: Authorization: Bearer <access_token>
• Response (JSON):
  • data : array of records
  • next_page : number or null

Example legacy record:

{
  "id": 123,
  "first_name": "Ada",
  "last_name": "Lovelace",
  "email": "ADA@EXAMPLE.COM",
  "created_at_epoch": 1700000000,
  "status": "ACTIVE"
}

3) New destination endpoint

• POST https://new.example.com/v2/records
• Headers:
  • Authorization: Bearer <access_token>
  • Content-Type: application/json
  • X-Checksum: <checksum>
  • (Optional but recommended) Idempotency-Key: <stable-key>
• Body: one transformed record per request (you can also justify batching if you prefer).

Transformation rules

Transform each legacy record into the following shape:

{
  "legacy_id": 123,
  "full_name": "Ada Lovelace",
  "email": "ada@example.com",
  "created_at": "2023-11-14T22:13:20Z",
  "is_active": true
}

Rules:

• legacy_id = id
• full_name = first_name + " " + last_name (trim extra spaces)
• email = lowercase(email)
• created_at = created_at_epoch converted to UTC ISO-8601
• is_active = (status == "ACTIVE")

Checksum requirement

Compute X-Checksum as:

• SHA-256 of the exact UTF-8 bytes of the JSON request body you send.
• Encode as lowercase hex.

(If you choose to canonicalize JSON to avoid key-order differences, explain your approach.)

Non-functional requirements

• Handle pagination until next_page == null .
• Refresh/re-acquire the token when expired.
• Retry transient failures (e.g., timeouts, 429, 5xx) with exponential backoff.
• Log progress (counts of fetched/transformed/sent; failures with reasons).
• The program should be restartable without duplicating writes (idempotency strategy).

Deliverables

• A short design explanation (1–2 pages) describing the approach.
• Implementation in a language of your choice.
• Tests for transformation + checksum logic, and a strategy for API mocking.