RedeemSG Integration Guide
  • Overview
  • PHASE 1: GETTING STARTED
    • Submit interest to NEA
    • Information provided
  • PHASE 2: INTEGRATION
    • Overview
    • API documentation
      • Introduction
      • Environment
      • Authentication
        • In event of leaked API key
      • Redeeming a QR code Voucher
        • POST /v1/vouchers/redeem
          • Attributes
          • Returns
        • Making Idempotent Redemption Requests
          • Introduction
          • Implementation and Details
      • Retrieving transactions
        • GET /v1/transactions
        • Request
        • Response
      • Errors
        • Overview
        • Error codes
      • Changelog
    • Tech requirement
      • Overall flow
      • Sales System Requirements
      • Reconciliation requirements
      • Changelog
    • Generate API keys
      • Login
      • Create API key
  • PHASE 3: UAT
    • Overview
    • Complete test cases
      • Create vouchers
      • Download test cases
    • UAT self-review
      • Review UAT results
    • Inform NEA
    • UAT with RedeemSG
      • UAT submission
    • What should I do if I have questions?
      • FAQs
      • Weekly office hours
  • PHASE 4: PRODUCTION TESTING
    • Production testing
      • Arrange date for prod testing
      • Test cases conducted
      • Items to prepare
      • FAQs
    • Ops readiness check
Powered by GitBook
On this page
  1. PHASE 2: INTEGRATION
  2. API documentation
  3. Redeeming a QR code Voucher

Making Idempotent Redemption Requests

4.2 Making Idempotent Redemption Requests

The redemption API POST /v1/vouchers/redeem supports idempotency to allow safe retries without unintentionally attempting a voucher redemption twice. This is useful when the API call is disrupted in transit and a response is not received.

Idempotency key should be the same when doing retries for the same QR. However, scanning different QR code should be with different idempotency key

PreviousReturnsNextIntroduction

Last updated 5 months ago