Overview
A job in MechZie follows a strict state machine from creation to payment. Understanding these states is critical for building the correct UI flows.State Machine
Status Reference
Creating a Job
service_category_id, pickup_address, pickup_lat, pickup_lng
Optional fields: vehicle_id, description, photo_urls
Dispatch System
After job creation, the system automatically dispatches to nearby mechanics in expanding tiers:
How it works:
- System finds available, verified mechanics within Tier 1 radius
- Filters by vehicle type (matches job’s vehicle type) and service category (double gate)
- Sends
job:offerSocket.io event to each matching mechanic - First mechanic to call
POST /jobs/{id}/acceptwins. Their availability flips to false. The winning mechanic’s other pending offers for different jobs are superseded. Other mechanics contacted for the same job get ajob:takenSocket.io event. - If the mechanic accepts another job, their pending offers for other jobs are superseded (revoked) and the mechanic receives a
job:offer-revokedSocket.io event. - If no one accepts within the timeout, expands to Tier 2, then Tier 3
- If all tiers exhaust → status becomes
no_mechanic_found
Mechanics only receive job offers for vehicle types they registered for. A mechanic who only services
two_wheeler will never receive offers for four_wheeler jobs.The customer sees the job status change from
pending → dispatching almost immediately. They receive job:status events via Socket.io as the state changes. Show a loading/searching animation during dispatching.Mechanic Registration
Before receiving job offers, a mechanic must register with their vehicle types and service categories:Updating Vehicle Types
Mechanics can update their vehicle type preferences after registration:Mechanic Actions (State Transitions)
Each transition is a simple POST:Authorization: Bearer ACCESS_TOKEN. Invalid transitions return 409 INVALID_TRANSITION.
Line Items (Parts & Labor)
Mechanics can add charges duringarrived or in_progress status:
When completed,
final_price = base_price + SUM(quantity × unit_price for all line items).
The customer receives a job:line-item-added Socket.io event in real-time.
Cancellation Rules
Fee Schedule
Checking Unpaid Fees
Listing Jobs
pending, dispatching, accepted, en_route, arrived, in_progress, completed, paid, cancelled, no_mechanic_found.
Job Detail
GET /api/v1/jobs/{id} returns an enriched response with nested related entities:
estimated_price is computed as base_price + sum(line_items quantity × unit_price). All prices are in paisa.Mechanic Public Profile
For a dedicated mechanic profile screen, useGET /api/v1/mechanics/{mechanicProfileId}. This endpoint exposes only customer-safe fields:
Frontend Integration Summary
Customer App Flow
- Create job → Show searching animation
- Listen for
job:status→ Update UI based on status - On
accepted→ Show mechanic info, start tracking job:join→ Join job room for location updates- Listen for
location:updated→ Animate map marker + show ETA - Listen for
job:line-item-added→ Show added parts/labor - On
completed→ Show final price, open payment flow - On
paid→ Show receipt, prompt for rating
Mechanic App Flow
- Listen for
job:offer→ Show accept/decline dialog (with timer) - On
job:takenorjob:offer-revoked→ Dismiss dialog if another mechanic accepted or mechanic is no longer available (e.g. accepted another job) - Accept → Navigate to job detail, start sending
location:update - Transition through states →
en-route→arrive→start→complete - Add line items during
arrived/in_progress - On
paid→ Show completion, prompt for rating
