[Feature Request] Allow Customize endpoint

[H0llyW00dzZ]

🥰 Feature Description

Currently, the customizable endpoint feature is not working as expected for external REST APIs, such as https://oneapi.b0zal.io. The issue seems to have arisen after the new developers started maintaining the project. The customizable endpoint keeps forcing the path to api.example.com/v1/message for Anthropic or other AI providers, which is causing compatibility issues.

🧐 Proposed Solution

To address this problem, I propose the following solution:

1. Modify the customizable endpoint feature to allow users to specify the complete API endpoint path, including the domain and any necessary subpaths.
2. Ensure that the specified endpoint path is used as-is, without any forced modifications or additions.
3. Implement proper validation and error handling to provide informative feedback to users if the specified endpoint is invalid or unreachable.
4. Update the documentation and user interface to clearly communicate the expected format and usage of the customizable endpoint feature.

By implementing these changes, users will have the flexibility to integrate with various external REST APIs seamlessly, without being limited to a specific path structure.

📝 Additional Information

• The issue seems to be related to the way the endpoint URL is constructed, as it always appends /v1/message to the user-specified endpoint.
• It would be helpful to gather feedback from users who have encountered this issue to understand their specific use cases and requirements.
• Thorough testing should be conducted to ensure that the modified customizable endpoint feature works as expected with a variety of external APIs.

[H0llyW00dzZ]

For example, allow customizing the endpoint securely, as shown in the following images:

The first image demonstrates a customizable endpoint configuration where users can specify the API endpoint URL, including the domain and any necessary subpaths. This allows for flexibility in integrating with various external REST APIs.

The second image shows an example of a secure configuration, where the API key is provided as an authentication mechanism. This ensures that only authorized users can access the endpoint and helps protect sensitive data.

By implementing these customization options, users can seamlessly integrate with their preferred AI providers or external APIs while maintaining a secure connection. The ability to specify the complete endpoint URL and provide authentication credentials enhances the versatility and security of the application.

[H0llyW00dzZ]

Also, for anyone who doesn't know about One API:

Information can be found here (English version):

• https://oneapi.b0zal.io/about

[Dogtiti]

我似乎有看到你在该仓库有很多代码贡献，如果可以的话，你愿意为此问题提供pr吗 非常感谢~

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

I seem to have seen that you have a lot of code contributions in this repository. If possible, would you be willing to provide a PR for this issue? Thank you very much~

[H0llyW00dzZ]

我似乎有看到你在该仓库有很多代码贡献，如果可以的话，你愿意为此问题提供pr吗 非常感谢~

@Dogtiti I have to figure this out again because this repository has changed a lot from the original version made by @Yidadaa.

Also, I am pretty sure that I have configured it to support a customizable endpoint. The relevant code can be found here:

• https://github.com/ChatGPTNextWeb/ChatGPT-Next-Web/blob/2474d5b6d2e85c4f0e8aef7984741ef91c201419/app/client/platforms/anthropic.ts#L378
• https://github.com/ChatGPTNextWeb/ChatGPT-Next-Web/blob/2474d5b6d2e85c4f0e8aef7984741ef91c201419/app/constant.ts#L144

The next step would be to implement a user interface for the customizable endpoint mechanism.

[H0llyW00dzZ]

Also I think it would be better to implement a provider for One API or a similar external API as a standalone (independently) provider, similar to the other providers. This is because it would be more complex to add the allow customize endpoint feature individually to every AI provider.

[H0llyW00dzZ]

Update Regarding These Issues

The Google provider also doesn't work (tested on the web version).

In v1, it keeps forcing the use of v1beta.