feat: integrate v3 user endpoints

[Ali-Sab]

Migrate user API calls from v1 to v3 SDK

• Introduces @kong/insomnia-api-sdk to insomnia-api and migrates user profile and encryption key fetching from v1 endpoints to GET /v3/users/me and GET /v3/users/me/encryption-keys.
• absorbKey now makes parallel v3 calls instead of a single whoami.
• Smoke test mocks updated accordingly.
• GET /auth/whoami is retained for the SRP login handshake.

[Copilot]

Pull request overview

This PR migrates Insomnia’s user/session bootstrap from legacy v1 user endpoints to the v3 user endpoints via the new @kong/insomnia-api-sdk, and wires up a configurable v3 base URL at app startup.

Changes:

• Configure the v3 SDK base URL during app startup (main + renderer) using getApiBaseURL().
• Update session initialization (absorbKey) to fetch profile + encryption keys from v3 in parallel.
• Update smoke-test API mocks and add new unit tests for the new v3 mapping layer.

Reviewed changes

Copilot reviewed 11 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
packages/insomnia/src/entry.main.ts	Configures v3 SDK base URL during main process startup.
packages/insomnia/src/entry.client.tsx	Configures v3 SDK base URL during renderer startup.
packages/insomnia/src/account/session.ts	Switches absorbKey to parallel v3 profile/key fetch + field mapping.
packages/insomnia/src/account/tests/session.test.ts	Adds/updates unit tests for absorbKey behavior.
packages/insomnia-smoke-test/server/insomnia-api.ts	Updates smoke-test server mocks to v3 user endpoints/fields.
packages/insomnia-api/vitest.config.ts	Adds Vitest config for the insomnia-api package.
packages/insomnia-api/src/v3-client.ts	Introduces v3 client factory + base URL configuration.
packages/insomnia-api/src/user.ts	Migrates profile + encryption key fetching to v3 SDK and maps fields.
packages/insomnia-api/src/index.ts	Exports configureBaseURL for consumers.
packages/insomnia-api/src/tests/user.test.ts	Adds unit tests for v3 user/key mapping and base URL config.
packages/insomnia-api/package.json	Adds @kong/insomnia-api-sdk dependency.
package-lock.json	Locks @kong/insomnia-api-sdk dependency.

Comments suppressed due to low confidence (1)

packages/insomnia/src/account/session.ts:45

• absorbKey resolves sessionIdResolved for the API calls, but still passes the original sessionId argument into setSessionData. If the caller passes an empty string (the intended fallback case), this will persist an empty session id and effectively clear the session even though the profile/keys were fetched using the resolved id. Use sessionIdResolved when storing the session data.

  const sessionIdResolved = sessionId || (await getCurrentSessionId());
  const [profile, keys] = await Promise.all([
    getUserProfile({ sessionId: sessionIdResolved }),
    getEncryptionKeys({ sessionId: sessionIdResolved }),
  ]);
  const { publicKey, encPrivateKey, encSymmetricKey } = keys;
  const { email, id: accountId, given_name: firstName, family_name: lastName } = profile;
  const symmetricKeyStr = crypt.decryptAES(key, JSON.parse(encSymmetricKey));

  // Store the information for later
  await setSessionData(
    sessionId,
    accountId,
    firstName,
    lastName,
    email,
    JSON.parse(symmetricKeyStr),
    JSON.parse(publicKey),
    JSON.parse(encPrivateKey),
  );

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ZxBing0066]

Is there any reason that we don't use @types/json-bigint?

[Ali-Sab]

If you mean why does this file exist and is not used... actually, this file is a mistake, seems I did some compilation out of order and the file wasn't generated by @types for some reason 🤔 , so I will delete this file as it's not needed

[ZxBing0066]

I'm curious why we use a JSON string instead of keeping the previous object. I think it's harder for parsing and checking.

[Ali-Sab]

That is because the SDK's type also stores them as strings, so in the smoke test I just generate the JSON, and keep it as string to match the type correctly. Here is a snippet from the SDK (public)

export interface UserEncryptionKeys {
    /**
     * The user's encrypted driver key
     * @type {string}
     * @memberof UserEncryptionKeys
     */
    readonly enc_driver_key: string;
    /**
     * The user's encrypted private key
     * @type {string}
     * @memberof UserEncryptionKeys
     */
    readonly enc_private_key: string;
    /**
     * The user's encrypted symmetric key
     * @type {string}
     * @memberof UserEncryptionKeys
     */
    readonly enc_symmetric_key: string;
    /**
     * The user's public key
     * @type {string}
     * @memberof UserEncryptionKeys
     */
    readonly public_key: string;
    /**
     * Salt used for encryption key derivation
     * @type {string}
     * @memberof UserEncryptionKeys
     */
    readonly salt_enc: string;
}

The risky changes have been revised

[ZxBing0066]

Considering the SDK module is currently private, it might be worth re-evaluating this approach. Keeping it private prevents other open-source contributors from installing and debugging effectively.

[Ali-Sab]

Considering the SDK module is currently private, it might be worth re-evaluating this approach. Keeping it private prevents other open-source contributors from installing and debugging effectively.

So I think they should still be able to call the endpoints, since we are only actually using the generated types. And the dev can output a response to see the data inside (treated as any), but you are right in that an open-source contributor cannot actually see the types themselves within the code and modify it. However, since the variable is treated as any, a dev can technically work with the output of the getUserProfile and getEncryptionKeys functions if they want to.

Given that, is it sufficient? Do we still think that making the SDK fully public would be better?