🏗️ ShramikConnect Backend – API Documentation (Current Progress)

This document describes all REST APIs implemented so far in the ShramikConnect .NET Web API backend.

The system supports multi-role users, job posting, applications, contracts, and admin management.

Important

Authentication: Currently uses a temporary X-User-Id header for development. JWT-based authorization will replace this in the next phase.

---

🔐 Authentication APIs

Register User

Creates a new user account (Worker / Client / Organization).

• Method: POST
• Endpoint: /api/auth/register
• Request Body:

  {
    "fullName": "John Doe",
    "email": "john@example.com",
    "phone": "9876543210",
    "password": "Strong@123",
    "role": 2
  }

• Notes: * Admin & Supervisor cannot self-register.
  • Password is securely hashed.
  • Profile is created later via profile APIs.

Login User

Authenticates user and returns JWT (and user info).

• Method: POST
• Endpoint: /api/auth/login

---

👤 Profile APIs

Used to update role-specific profile details after account creation.

Action	Method	Endpoint
Update Worker Profile	PUT	/api/profile/worker
Update Client Profile	PUT	/api/profile/client
Update Organization Profile	PUT	/api/profile/organization

Notes:

• Profiles are updated (not recreated).
• No duplicate profile rows are created.

---

🧑‍💼 Admin User Management APIs

Accessible to Admin role only.

• Get All Users: GET /api/admin/users
• Get User by ID: GET /api/admin/users/{userId}
• Update User (Core Info): PUT /api/admin/users/{userId}
  • Editable Fields: Full name, Phone, Active status.
• Soft Delete User (Deactivate): DELETE /api/admin/users/{userId}
  • Sets IsActive = false.
  • Preserves all history and relations.
• Hard Delete User (Permanent): DELETE /api/admin/users/{userId}/hard
  • Deletes user and related profiles.
  • Intended for test data or GDPR cases.

---

💼 Job APIs

• Create Job: POST /api/jobs
• Get All Jobs: GET /api/jobs
• Get Job by ID: GET /api/jobs/{jobId}
• Get Jobs Posted by User: GET /api/jobs/posted-by/{userId}
• Get Jobs by Category: GET /api/jobs/category/{category}
  • Example: /api/jobs/category/Painting
• Edit Job: PUT /api/jobs/{jobId} (Only job owner can edit)
• Toggle Job Status: PATCH /api/jobs/{jobId}/toggle-status
  • Toggles between Open ↔ Closed.
  • Job can be reopened or closed anytime; no deletion.

---

📄 Job Application APIs

• Apply to Job (Worker): POST /api/job-applications/apply
• View Applicants (Client/Org): GET /api/job-applications/job/{jobId}
• Start Discussion: PATCH /api/job-applications/{applicationId}/start-discussion
  • Marks application as InProcess.
  • Enables chat & contract creation.
• View My Applications (Worker): GET /api/job-applications/my-applications
• Withdraw Application (Worker): PATCH /api/job-applications/{applicationId}/withdraw
  • Rules: Allowed only if status is Applied or InProcess. Not allowed after acceptance.

---

📜 Contract APIs

Contracts are created only after application enters discussion (InProcess).

• Create Contract: POST /api/contracts
• Update Contract Terms: PUT /api/contracts/{contractId} (Client only – Pending status)
• Get Contract by Job: GET /api/contracts/job/{jobId}
• Accept Contract (Worker): PATCH /api/contracts/{contractId}/accept
  • Effects: Contract → Accepted; Application → Accepted; Job → Closed; Other applications → Rejected.
• Reject Contract (Worker): PATCH /api/contracts/{contractId}/reject

---

🔁 Application & Contract Lifecycle

1. Job Posted
2. Worker Applies
3. Client Starts Discussion (InProcess)
4. Contract Created (Pending)
5. Worker Accepts / Rejects

---

🧪 Temporary Authentication (DEV ONLY)

X-User-Id Header Used temporarily to simulate authentication.

• Key: X-User-Id
• Value Example: 5

Warning

This will be fully replaced by JWT claims in the next phase.