ABDM Error Coverage Checklist
1. Already Mapped
These are covered by the shared ABDM normalizer and should already render a human-readable message in the app.
Invalid CredentialsMissing CredentialsInvalid JWT tokenInvalid X-token/Invalid X Auth tokenInvalid T-tokenInvalid access tokenInvalid client id/Invalid client secretAccess DeniedNot authorizedInvalid ScopeInvalid LoginIdInvalid Login HintInvalid Auth MethodsInvalid OTP RequestInvalid OTP ValueInvalid transaction idInvalid request IDRequestId cannot be NULL or BlankInvalid ConsentIdInvalid Consent request idInvalid Consent artefact idInvalid purpose textInvalid consent purpose refURIInvalid from/to dateInvalid date range, from date should be less than to dateInvalid Service IDInvalid HIP IDABHA address and Link token mismatchDuplicate Discovery requestDuplicate On discovery requestDuplicate Init requestDuplicate Confirm requestDuplicate On confirm requestThis care context has already been linkedCounter and Care context count mismatchGender is invalidInvalid ABHA Number or ABHA AddressThis mobile number is already verifiedThis ABHA address already existsserver cannot find the requested resourceNo matching resource found for given API RequestDependent service unavailableUnclassified Authentication FailureService UnavailableInvalid requestBad Request, invalid request Body
2. Mapped But Worth Watching
These are covered, but they are used across multiple flows or have overlapping wording, so they are worth keeping an eye on during future Swagger additions.
Invalid transaction idInvalid requestInvalid ABHA numberInvalid ABHA addressInvalid statusInvalid OTP RequestInvalid JWT tokenAccess DeniedInvalid CredentialsInvalid ResponseUnclassified Authentication Failure
3. Still Missing Or Not Worth Mapping Yet
These are either success responses, non-actionable documentation text, or phrases that did not look useful as reusable UI errors.
Successfully approved Subscription requestSuccessfully denied Subscription requestSubscription enabled successfullySubscription disabled successfullyAcceptedInternal Server Errorgeneric labels without a more specific description- Long explanatory descriptions that do not represent a specific user-facing failure
Notes
- If a Swagger example uses a generic wrapper such as
Runtime Error,Status report, orInvalid Credentials, the normalizer should prefer the more specificdescriptionor payload text when available. - When a future Swagger introduces a new phrase that is very close to an existing one, check whether it should be folded into the current matcher before adding a brand-new rule.