As a ReportStream sender I want to have clear documentation of the Submission History API showing a complete list of errors my reports might generate so that I can understand what error I've gotten and how to fix it before submitting the fixed message
Description/Use Case
Multiple types of senders ranging from core senders on the pipeline to partners like ETOR Flexion and NIH's API Wrapper team have expressed a need for documentation surrounding the Submission History API from the basics of how to hit the endpoint to what the error codes it responds with means. This documentation would help users proactively find and solve errors in their submissions as well as help our Support Team in answering questions around errors that arise from senders over time.
Risks/Impacts/Considerations
Risk/dependency: if the completed documentation is not easily discoverable for users they may still not use it and instead keep reaching out for help and clarification of their errors.
Dev Notes
The documentation can be written and housed in Github unless design raises a need for a ReportStream website version
The bulk of the work is in filling out the SubmissionHistoryAPI Values & Responses Table specifically ensuring that the list of error codes listed starting row64 is exhaustive and every code has an accompanying message value and meaning field filled out. This is what users will be parsing when they get an error to find a solution.
Acceptance Criteria
[ ] All errors codes have been tested to understand it's relevance in the UP and have it documented or to find the error code is no longer used or useful to the UP and is removed from the codebase and marked as such in the SubmissionHistoryAPI sheet
[ ] Submission History API documentation exists with sections on pinging the API, status codes, and error codes filled out
[ ] SubmissionHistoryAPI Values & Responses Table is complete and ported to the user facing documentation such that users can read it to find their error code and understand the meaning of the error
jsutantio
commented
1 week ago
User Story
As a ReportStream sender I want to have clear documentation of the Submission History API showing a complete list of errors my reports might generate so that I can understand what error I've gotten and how to fix it before submitting the fixed message
Description/Use Case
Multiple types of senders ranging from core senders on the pipeline to partners like ETOR Flexion and NIH's API Wrapper team have expressed a need for documentation surrounding the Submission History API from the basics of how to hit the endpoint to what the error codes it responds with means. This documentation would help users proactively find and solve errors in their submissions as well as help our Support Team in answering questions around errors that arise from senders over time.
Risks/Impacts/Considerations
Risk/dependency: if the completed documentation is not easily discoverable for users they may still not use it and instead keep reaching out for help and clarification of their errors.
Dev Notes
The documentation can be written and housed in Github unless design raises a need for a ReportStream website version The bulk of the work is in filling out the SubmissionHistoryAPI Values & Responses Table specifically ensuring that the list of error codes listed starting row64 is exhaustive and every code has an accompanying message value and meaning field filled out. This is what users will be parsing when they get an error to find a solution.
Acceptance Criteria