Where it lives
The status page is hosted at https://cdn.tagpipes.com/shield/status.html on CloudFront. It's a single static HTML file with a small JavaScript form that POSTs to the Shield intake Lambda's /status endpoint. No authentication, no TagPipes login. The reference plus email combination is the access token.
What requesters see
The page asks for two fields: Reference Number (the DSAR-YYYYMMDD-XXXX code from their confirmation email) and Email Address (the one they used when submitting). If both match a live request, the page shows:
- Reference number echoed back
- Status pill: Received, Acknowledged, In Progress, Completed, or Decision Made
- Request type
- Submission date
- Response deadline
- Completion or decision date (when closed)
- Reject reason in a highlighted block (when rejected)
- Support email contact line in the footer
Deep links from emails
The acknowledgment, completion, and rejection emails all include a "You can check the status of your request at any time at..." line that links to the page with the reference pre-filled via ?ref=DSAR-... URL parameter. The requester only has to type their email; the reference auto-populates.
Anti-enumeration design
All four "not found" cases return the same generic envelope {`{ found: false, message: "No request matches that reference and email." }`}:
- Reference exists, email does not match
- Reference format is invalid (regex check against DSAR-\d{`{8}`}-[A-Z0-9]{`{4}`})
- Reference is well-formed but never existed
- Reference was auto-purged after retention window
A malicious party hitting the endpoint with random references and random emails cannot tell which references exist. They only ever see one of two responses: "found, here is your data" (for the exact requester) or "no match" (for everything else).
Garbage references like "banana" are rejected by regex before the Lambda even scans DynamoDB. Same generic envelope returned, but no database hit. This protects the request table from junk-input scan storms.
Branding
The status page uses generic TagPipes Shield branding for now. The Questions? Contact... line in the result panel surfaces the form's support email plus company name, so requesters see your company in the response payload even though the page chrome is platform-branded. Per-company branded status pages are on the Phase 4 backlog if a client needs them.
Configuration
The status page URL embedded into emails is configurable but defaults sensibly. The web app reads Shield.StatusPageUrl in web.config. The intake Lambda reads STATUS_PAGE_URL in its environment. Both default to the CDN URL. Changing them rewires the deep-link in subsequent emails; already-sent emails keep their original link.
Troubleshooting
Requester says the link in their email is broken
Confirm the reference in the deep link matches a live request. If the request was auto-purged after the retention window, the status page will return "no match" even though the requester remembers submitting. Check Shield Settings for AutoPurgeDays and the date of the original submission.
Requester says status page shows wrong status
The status page reads live from DynamoDB on every check. Wrong status here means wrong status in Shield. Open the request in the admin and confirm the current state, then close the loop with the requester directly.
Requester says the support email shown is wrong
The footer pulls from the form's Support Email field (not Settings). If multiple forms exist for a company with different support emails, check which form the request came from (form_id on the request) and update that form's Support Email then re-publish.