Inconsistent Authorization Behavior in Hoppscotch (Works in Postman, Fails in Specific Endpoints)

🧩 Summary

I am experiencing inconsistent behavior when using Hoppscotch for API testing.

• All requests work correctly in Postman
• Most requests work in Hoppscotch
• But a specific group of endpoints (Faculty APIs) consistently fail in Hoppscotch
• The same requests succeed in Postman with identical configuration

This makes it difficult to use Hoppscotch reliably in a team workspace setup.

⚙️ Setup

• Client: Hoppscotch (Desktop - Linux)
• Also tested on: Hoppscotch Web
• Comparison tool: Postman
• Auth type: Bearer Token (set at collection level, inherited by requests)
• Request type: multipart/form-data

✅ Working Endpoints

All of the following work correctly in Hoppscotch:

• Student APIs
• Library APIs
• Other endpoints using the same token and environment

❌ Failing Endpoints

The following endpoints fail only in Hoppscotch:

• Faculty APIs (e.g. /API/FacultyInfo/GetTimeTable, /API/FacultyInfo/GetCoursesList etc. )

Response:

<div style="border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;">
<h4>A PHP Error was encountered</h4>
<p>Severity: Notice</p>
<p>Message:  Undefined index: Authorization</p>
</div>
<div style="border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;">
<h4>A PHP Error was encountered</h4>
<p>Severity: Notice</p>
<p>Message:  Undefined offset: 1</p>
</div>{"status":"403","message":"Please enter the API Token."}

🔍 What Has Been Verified

I have carefully tested and ruled out the following:

✔ Token Issues

• Token is generated correctly
• Same token works in other endpoints
• Hardcoded token also tested

✔ Authorization Header

Hoppscotch plugin:execute|replay -> Headers -> request data (from network logs):

{
  "request": {
    "headers": {
      "Authorization": "Bearer eyJ0eXAiOiJqd3QiLCJhbGciOiJIUzI1NiJ9********************NxI",
      "content-type": "multipart/form-data",
      "User-Agent": "HoppscotchKernel/0.2.0"
    },
    "auth": {
      "kind": "bearer",
      "token": "eyJ0eXAiOiJqd3QiLCJhbGciOiJIUzI1NiJ9********************NxI"
    }
  }
}

• Header is present
• Token format is correct

✔ Environment / Variables

• baseURL resolves correctly
• TOKEN resolves correctly

✔ Auth Inheritance

• Authorization is set at collection level
• Requests inherit auth
• Works for other folders

✔ Request Structure

• Same method (POST)
• Same endpoint
• Same body structure
• Same content type

🔬 Critical Observation

Backend behavior differs depending on whether the Authorization header is actually received:

Example Error (when header is missing or not detected)

<div style="border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;">
<h4>A PHP Error was encountered</h4>
<p>Severity: Notice</p>
<p>Message:  Undefined index: Authorization</p>
</div>
<div style="border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;">
<h4>A PHP Error was encountered</h4>
<p>Severity: Notice</p>
<p>Message:  Undefined offset: 1</p>
</div>{"status":"403","message":"Please enter the API Token."}

Key Insight

Even though Hoppscotch shows the Authorization header in request logs:

"Authorization": "Bearer <TOKEN>"

👉 The backend behaves exactly as if the header is not present at all

Conclusion from Observation

This strongly suggests that:

• The Authorization header is not being received or parsed correctly by the backend when sent from Hoppscotch
• The same header works correctly when sent from Postman
• Therefore, the issue is likely related to how Hoppscotch sends the request at a lower level (transport/formatting) rather than token validity

🔁 Comparison with Postman

Postman Request (Working)

curl --request POST \
  --url https://example.com/API/FacultyInfo/GetTimeTable \
  --header 'Authorization: Bearer <TOKEN>' \
  --form emp_code=XXXX

Hoppscotch Request (Failing)

{
  "url": "https://example.com/API/FacultyInfo/GetTimeTable",
  "method": "POST",
  "headers": {
    "Authorization": "Bearer <TOKEN>",
    "content-type": "multipart/form-data"
  },
  "body": {
    "emp_code": "XXXX"
  }
}

⚠️ Key Problem

Even though:

• Authorization header is clearly present in Hoppscotch
• Token is valid
• Same request works in Postman

👉 The backend behaves as if no token was sent at all

🧠 Hypothesis

This appears to be a transport-level or formatting issue, not a logical/auth issue.

Possible causes:

• Header formatting differences (invisible characters, casing, encoding)
• Multipart request formatting differences (boundary handling)
• Differences in HTTP stack (Hoppscotch vs Postman)
• Backend parsing limitations (PHP / server config)
• Authorization header not being parsed correctly for certain requests

❓ Questions

1. Does Hoppscotch handle Authorization headers differently for multipart requests?
2. Could Hoppscotch be sending headers in a format that some backends fail to parse?
3. Are there known issues with Authorization headers + multipart/form-data?
4. Any way to inspect raw outgoing HTTP request (wire-level) from Hoppscotch?

🎯 Expected Behavior

• If Authorization header is present, backend should receive and validate it
• Same request should behave identically across clients

❌ Actual Behavior

• Hoppscotch sends Authorization header
• Backend behaves as if it is missing
• Only happens for specific endpoints

📎 Additional Notes

• This issue is blocking team adoption of Hoppscotch in place of Postman
• Behavior is reproducible across multiple users
• Not environment-specific

🙏 Request

Would appreciate help in:

• Identifying whether this is a Hoppscotch issue or backend compatibility issue
• Debugging how headers are actually sent at a lower level
• Suggesting a workaround if this is a known limitation

Thanks in advance for any guidance 🙌