Project Description
NEED TO BE DONE IN LESS THAN 24 HOURS
MAKE SURE U DM ME IF UR INTRESTED AND WHAT U BID IS WHAT U GET
Work is Done ON WEBOOK.COM
-----------------
Objective
Recover a competitive API hold path (if still possible) and improve hold performance under heavy competition.
Current behavior is mainly:
WS + ChartRender fallback
Hold-only mode (no auto-checkout)
Multi-holder distributed accumulation
Primary problem: API hold path is effectively unavailable on target events, so fallback path loses races.
What Works Now
Event detail fetch works (event_id, event_key, workspace, pricing, limits).
Session restore + token bridge works.
Seat discovery/polling works.
ChartRender selectObjects executes very fast (few ms).
Hold-only flow is strict (no checkout automation).
What Fails Now
API hold endpoints appear dead/blocked for current event path (v2 hold disabled behavior).
Frequent Selection not confirmed in chart state after fast selection.
WS reconnect storms / token churn create delay and missed race windows.
Competitors confirm holds while our flow is still in fallback/confirm loops.
Required Freelancer Scope
A) API Endpoint Investigation (Main Task)
Verify if API hold is truly removed, or blocked by auth/fingerprint/headers/payload mismatch.
Test alternate endpoint families and payload contracts for the same event context.
Provide proof: request/response matrix (status, body shape, required headers/tokens).
B) If API Is Recoverable
Implement production-safe API hold path with fallback hierarchy.
Add strict success criteria (no fake held counting).
Keep latency low and avoid blocking the hot path.
C) If API Is Not Recoverable
State it clearly with technical evidence.
Provide best-possible WS/ChartRender optimization plan and patch.
Important Technical Note: May Need Spoofing
This recovery may require browser-like spoofing/parity, such as:
TLS/client fingerprint parity
Exact header profile (sec-ch-*, origin/referer, auth, queue token)
Request timing/order parity
Browser-derived tokens or challenge fields
Potential browser-assisted signing/token extraction flow
Freelancer must document exactly which spoofing/parity elements are required and why.
Hard Constraints
Keep hold-only behavior strict (no checkout side effects).
No fake success notifications.
No broad refactor outside scoped files.
No secrets required from owner.
Success Criteria
Fewer confirm failures under identical race conditions.
Lower median hold-confirm latency.
No false-positive held counts.
Clear technical verdict on API recoverability:
Recoverable path + patch, or
Not recoverable + evidence + best fallback design.