Access Token Request (v1 ➞ v2)

✨ Why Migrate?

• Improved Security: V2 uses Basic Authentication with base64 encoding.

• Standards Compliance: V2 uses application/x-www-form-urlencoded, aligning with OAuth 2.0.

• Detailed Response: Includes token_type, expires_in, and other standard fields.

---

↺ What Changed?

Feature	API v1	API v2
Endpoint	/api/v1/Token	/api/v2/token
HTTP Method	POST	POST
Authorization Header	Bearer <access_token>	Basic base64(client_id:client_secret)
Content-Type	application/json	application/x-www-form-urlencoded
Body Format	JSON	Form-Encoded
Response Format	{ authToken, refreshToken }	{ access_token, refresh_token, token_type, expires_in }

---

📁 Migration Steps

✅ Before (API v1)

POST https://evia.enadocapp.com/_apis/falcon/auth/api/v1/Token
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "client_id": "<client_id>",
  "client_secret": "<client_secret>",
  "code": "<authorization_code>",
  "grant_type": "authorization_code"
}

✅ After (API v2)

POST https://evia.enadocapp.com/_apis/falcon/auth/api/v2/token
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
client_id=your-client-id&
client_secret=your-client-secret&
code=received-auth-code

---

🔄 Response Comparison

❌ v1 Response

{
  "authToken": "Auth Token",
  "refreshToken": "Refresh Token"
}

✅ v2 Response

{
  "access_token": "abc123...",
  "refresh_token": "abc1asas23...",
  "token_type": "bearer",
  "expires_in": 3600
}

---

🔀 What Remains the Same

• You still use authorization_code as the grant_type.

• You still provide client_id, client_secret, and code.

---