Amazon Shift Automation System

I want to build a complete server-side automation system that performs the entire authorized Amazon shift workflow without requiring a browser or browser extension on the user's computer.
Goal
The server should handle the complete workflow from authentication through shift detection and, where authorized, shift claiming.
The system should behave like a normal authorized client of the service and maintain the required authentication/session state automatically.
Authentication & Session Management
The system should be capable of handling all legitimate authentication/session information required by the service, including dynamically obtained values such as:
CSRF tokens
Session cookies
Authorization/session tokens
Candidate ID
Account identifiers
Required request headers
Session state
Other non-secret request parameters required by the authorized interface
Do not hard-code temporary tokens or IDs. The system should obtain and refresh them dynamically whenever the authorized interface requires them.
If a value expires, changes, or becomes invalid, the system should detect this and establish a new authorized session.

THE INTERFACE SHAULD LOOKS LIKE A UPLOADED PICTURES.

Server-Side Workflow
The complete workflow should be handled by backend services:
Start an authorized account session.
Perform the permitted authentication process.
Maintain cookies and session state.
Obtain required CSRF/security tokens through the normal authorized flow.
Obtain the account's required candidate/account identifier.
Maintain required authorization state.
Retrieve available shifts through the permitted interface.
Continuously monitor for new shifts.
Apply configured shift filters.
When a matching shift is found, submit the authorized shift-claim request if the interface permits it.
Verify the result.
Store the transaction/result.
Notify the account owner.
Continue monitoring.
No Browser Dependency
The application should run entirely on a Linux VPS.
Do not require:
Chrome
Firefox
Selenium
Playwright
Browser extensions
Manual browser sessions
Use server-side HTTP/API clients and background workers.

Multi-Account Architecture
Support multiple authorized accounts concurrently.
Each account should have isolated:
Credentials/secrets
Session cookies
CSRF state
Authorization state
Candidate ID
Shift preferences
Monitoring worker
Shift history
Logs
Sensitive authentication information must never be exposed in logs.
Reliability
The system should automatically handle:
Expired sessions
Expired CSRF tokens
Authentication failures
Temporary network errors
Request timeouts
Server restarts
Worker crashes
Duplicate shift detection
Shift no longer being available
Retry/backoff logic
Use persistent storage so the system can recover its state after a restart.

bypass all the following things if required.
CAPTCHA
MFA/security challenges
Bot detection
Rate limits
Access controls
Authentication protections
Other security mechanisms

Build a standalone, production-ready Shift Filter module for my server-side Amazon shift management system.
Use the attached dashboard screenshot as the UI/UX reference for the filter structure.
The purpose of this module is to let each authorized user define exactly what type of shifts they want the system to detect and, where permitted, attempt to claim.
FILTER FIELDS:
1. Job Type
Provide selectable options:
- Full-time
- Part-time
- Flex-time
- Flex-time & Part-time
- Full-time & Part-time
- Full-time & Flex-time
2. Shift
Provide:
- Day Shift
- Night Shift
- Any Shift
3. Locations
Provide a searchable multi-select list of locations.
The user must be able to:
- Search locations by name
- Select multiple locations
- Remove individual selections
- Select/unselect locations easily
- Store the selected locations per user
Include locations such as:
- Acheson
- Ajax
- Balzac
- Barrhaven
- Belleville
- Bolton
- Brantford
- Brampton
- Burnaby
- Calgary
- Cambridge
- Coquitlam
- Concord
- Delta
- Dartmouth
- Edmonton
- Etobicoke
- Hamilton
- Kitchener
- Langley
- London
- Milton
- Mississauga
- New Westminster
- Nisku
- Oakville
- Ottawa
- Pitt Meadows
- Richmond
- Richmond Hill
- Rocky View County
- Scarborough
- Sidney
- St. Thomas
- Stoney Creek
- Toronto
- Tsawwassen First Nation
- Whitby
- Windsor
- Winnipeg
Make the location list configurable from the backend so additional locations can be added without changing the frontend code.
4. Previously Worked on Amazon?
Provide:
- Yes
- No
If "Yes" is selected, show:
- Badge ID
- Location Code
- From date
- To date
If "No" is selected, hide these fields.
5. Additional Note
Add an optional free-text field for user-specific instructions.
FILTER LOGIC:
The filter must be implemented on the backend, not only in the frontend.
When a shift is received by the monitoring service, normalize its information and evaluate it against the user's saved filter.
Example:
User configuration:
- Job Type: Full-time
- Shift: Night Shift
- Locations: Toronto, Mississauga
- Previously worked: Yes
Incoming shift:
- Job Type: Full-time
- Shift: Night
- Location: Toronto
Result:
MATCH
Incoming shift:
- Job Type: Part-time
- Shift: Night
- Location: Toronto
Result:
NO MATCH
The filtering engine should support multiple selected options and clearly define whether multiple selections are treated as OR conditions within the same category and AND conditions between categories.
IMPORTANT:
The filter should be independent from the shift-monitoring/claiming system.
Create it as a reusable service/module:
ShiftFilter
├── UserFilterProfile
├── JobTypeFilter
├── ShiftTypeFilter
├── LocationFilter
├── PreviousAmazonEmploymentFilter
└── MatchEngine
The backend should expose APIs to:
- Create filter
- Get filter
- Update filter
- Delete/disable filter
- Test a shift against a filter
- Return the reason a shift matched or failed

The UI should closely follow the attached screenshot's general layout while making it cleaner, responsive, and suitable for desktop and mobile.
Save every user's filter configuration in the database.
Make the filter engine fast enough to evaluate a large number of incoming shifts and multiple user profiles.
Do NOT hard-code filtering into the browser. The server must be the source of truth for filtering.
The module should be designed so it can later be connected directly to the server-side shift monitoring and authorized shift-claiming service.

I want the system to log in to Amazon automatically using the provided Amazon email/username and password. For OTP/2FA, use the Google Authenticator TOTP secret key provided by the account owner to generate the OTP automatically and complete the login process.