Search jobs with filters
Search jobs. Each job’s configured questions[] carry question_type + metadata (ScreeningQuestionConfig schema). Where applicant answers are returned, answers[] items follow the ScreeningAnswer schema (answer_type + answer_payload).
*
- With
job_idthis is the deal-detail lookup, and access to an invite-only deal is decided - here rather than by the caller (ENG-1697). An agent is answered through the athletes they
- currently represent: if any of them holds an invitation, application or hire on the deal,
- it opens. The agent needs no invitation of their own, which is the case that used to come
- back as an empty success the clients rendered as Deal not found. Pass
athlete_idto ask - about one represented athlete; the rest of the roster then does not answer for them.
- An athlete is answered by their own invitation, and the brand always sees its own deal.
- A refusal is now explicit: 403 when the caller has no invitation behind them, 404 when the
- deal is deleted or missing. Neither is an empty 200 any more.
Authorizations
JWT Bearer token authentication. Use the /api/login endpoint to obtain a token.
Query Parameters
Page number
1
Items per page (default 10)
10
Body
Search keyword (matches job name and creator name)
"test"
Array of category IDs
Filter by payment mode
Cash, Product null
Filter by state/location
null
Minimum price filter
100
Maximum price filter
10000
Sort order
pay_highest, name_asc, name_desc, most_recent "most_recent"
Filter by specific job ID
1
Athlete ID (for agent context)
123
Bypass job view preference filter
Y "Y"
Show only current user's jobs
Y "Y"
Ignored when job_id is sent: the server decides that case from the caller's own invitations (ENG-1697). Sending it never opens a deal the caller was not invited to. Still read on a list request.
Y "Y"
Response
Search results