1. Scope
This notice covers the current Courier Flow application. It must be updated before production if ordering, payments, precise location tracking, courier onboarding or other material processing is enabled.
2. Data currently handled
The application is designed to handle the following categories:
- Account data: name, email address, phone number, role, password hash and verification timestamps.
- Authentication and security data: sessions, challenge metadata, IP address, user agent and rate-limit records.
- Delivery data is not yet represented in the current database model. Before it is enabled, this notice must describe addresses, recipient details, instructions, status history and any location data actually collected.
3. Why data is used
Current processing supports account creation, sign-in, email verification, password reset, session management, abuse prevention and transactional service messages. A final notice must identify the applicable legal bases for the launch market.
4. Legal bases
The operator has not yet published a final legal-basis assessment. Depending on the launch market and purpose, processing may need to rely on contract, legal obligations, legitimate interests or consent. Each purpose must be mapped and documented before production; this list is not a claim that every basis applies.
5. Recipients and service providers
Account data is stored in the configured database, and email addresses are sent to the configured transactional email provider when verification or password-reset messages are requested. The operator must identify its actual hosting, database, email and other processors, locations and transfer safeguards before production.
6. International transfers
Whether personal data crosses national borders depends on the operator’s deployment and provider locations. No final transfer inventory or safeguard is stated here. The operator must document destinations and any required adequacy decision, contract or other safeguard before production.
7. Retention
Sessions and verification challenges have configured expiry periods, while account records currently have no published deletion schedule. Exact retention and deletion rules must be defined and documented before production.
8. Security
The application hashes passwords and authentication secrets and restricts protected pages to authenticated users. These controls reduce risk but cannot guarantee absolute security; deployment configuration, access controls, backups and incident response require separate review.
9. Cookies
The application uses a necessary authentication session cookie for signed-in access. Locale middleware may store a language preference depending on deployment. No advertising-cookie use is documented in the current code, but the final deployment must be audited and any required choices or notices added.
10. Requests and rights
Access, correction, deletion, restriction, portability, objection and other rights depend on applicable law and may have exceptions. Requests should go to the configured contact above. The operator must define identity checks, response procedures and deadlines before production.
11. Questions and complaints
Contact the operator first using the details above. The competent privacy authority and any right to complain depend on the operator’s establishment and the user’s location, so final authority information must be added after jurisdictional review.