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
  4. Making Idempotent Redemption Requests

Implementation and Details

PreviousIntroductionNextRetrieving transactions

Last updated 6 months ago

4.2.2 Implementation and Details

To perform an idempotent request, provide an additional Idempotency-Key: <key> header to the redemption request.

# Example of a v4 uuid idempotency key
-H "Idempotency-Key: af9be4e3-685d-4384-99c7-11774722d930"

RedeemSG’s idempotency key works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeded or failed. Subsequent requests with the same key return the same result. This applies to 2xx and 4xx responses.

An idempotency key is a unique value generated by the client (on your side) which the server uses to recognize subsequent retries of the same request. How you create unique keys is up to you, but we suggest using V4 UUIDs, nanoID, or another random string with enough entropy to avoid collisions. Idempotency keys can be up to 255 characters long.

Keys are eligible to be removed from the system automatically after they are at least 24 hours old, and a new request is generated if a key is reused after the original has been pruned. The idempotency layer compares incoming parameters to those of the original request and errors unless they're the same to prevent accidental misuse.

If the request conflicted (same request body & idempotency key) with another request that was executing concurrently, no idempotent result is saved. It is safe to retry these requests.