DEF-025 — POST /register field naming is inconsistent with the rest of the API

Defect DEF-025 — Severity: High · Status: New

DEF-025 — POST /register field naming is inconsistent with the rest of the API

Summary

The registration endpoint uses a different field naming convention and requires additional fields that no other endpoint in the API uses. Where the rest of the API uses standard JSON fields, registration requires full_name (a single combined name field) alongside confirm_password, fcm_token, and device_type — making this endpoint behave like a different product. Combined with DEF-023 (login also requiring device fields), the entire auth flow is inconsistently designed.

Environment

• Platform: DriveLink Backend API
• Server: https://project6.dxtserver.com/drivelink_new/public/api/v1
• Area: Authentication / Registration
• Requirement(s): FR-01 (User Registration)
• Date Reported: 2026-06-17
• Testing Phase: Backend API Testing

Steps to Reproduce

1. Send POST /register with the minimum expected fields for creating an account:

{
  "email": "newuser@example.com",
  "phone": "501234567",
  "dial_code": "+971",
  "password": "Testing@2026"
}

2. Observe which additional fields the server demands.

Expected Behaviour

Registration requires the user’s identity information and credentials. Password confirmation, device tokens, and FCM fields are either optional or handled separately.

Actual Behaviour

The server returns multiple validation errors for fields that are not standard registration inputs:

{
  "status": "0",
  "message": "The full name field is required.",
  "errors": {
    "full_name": ["The full name field is required."],
    "confirm_password": ["The confirm password field is required."],
    "fcm_token": ["The fcm token field is required."],
    "device_type": ["The device type field is required."]
  }
}

Full Working Request

{
  "full_name": "Test User",
  "email": "newuser@example.com",
  "phone": "501234567",
  "dial_code": "+971",
  "password": "Testing@2026",
  "confirm_password": "Testing@2026",
  "is_social": "0",
  "device_type": "android",
  "fcm_token": "<firebase_token>"
}

Impact

• The registration endpoint requires a device to be present at account creation time — a user cannot create an account from a web browser or server-side script
• full_name as a single field contradicts the user profile model which has separate first_name and last_name fields — these are populated as empty strings after registration, leaving profile data incomplete
• confirm_password validation belongs in the client (mobile app), not the server — the server has no way to know whether the user typed the same password twice; it only knows the two strings match
• Inconsistency across the auth flow (register, login, logout all have different patterns) increases integration effort significantly

Severity

High

Status

New

Reported By

QA / Testing Team