Provide Avni AI Assistant Config setting as an internal API response

[himeshr]

Motivation

Currently, we have hardcoded the Avni AI Assistant Chat token.
There might be future configurations that are needed while initializing Avni AI Assistant based on Env/ Org/ User, etc.

Therefore, it would be ideal if Avni-server would provide an API, which could be called by Avni Webapp, to obtain the Avni AI Assistant Config settings.

Acceptance Criteria

• Update/config add copilotConfig in its response object
• API is not protected and does not need auth as of now
• API returns JSON configuration containing : avni_copilot_token , avni_copilot_enabled (boolean), baseUrl
• API returns 200 OK with config data when valid request is made
• Avni-webapp replaces hardcoded token with API call in DifyChatbot component
• Webapp gracefully handles API errors by falling back to hiding the chat button

Request

GET /config

Happy path Response

Status Code: 200 OK

Response Body:

{
  "reportingSystems": [],
  "copilotConfig": {
    "avni_copilot_token": null,
    "avni_copilot_enabled": false,
    "base_url": "https://localhost:8021"
  }
}

Visual Design

No UI changes required for this API implementation. The visual experience remains the same:

• Chat button appears in bottom-right corner when config is successfully loaded
• Chat button is hidden if API fails (current behavior)
• Chat panel slides in from right when opened (existing design)
• Error states are handled gracefully without visual disruption

Future Enhancement

• Config response is modifiable based on env, user, user-group, org, org-config, usage, etc..
• Loading spinner on chat button while fetching config
• Toast notification for configuration errors (non-disruptive)
• Admin panel UI for managing AI assistant configurations per organization
• Configuration supports enabling/disabling AI assistant per organization
• AI Config API supports future extensibility for additional config parameters (custom prompts, feature flags, etc.)
• Webapp caches config response for session duration to avoid repeated API calls

This API-first approach provides the flexibility requested in the motivation while maintaining backward compatibility and allowing for future enhancements like per-organization customization, feature flags, and advanced configuration options.

[himeshr]

Discussion Notes:

• No auth in current version
• Org, user and userGroup agnostic endpoint