Hi,
Thanks for taking the time to share your feedback. That said, many of these concerns could have been clarified quickly if you had contacted our support team—we didn’t receive any message from you.

To explain things in simple terms:

1. Security and allowed domains
We provide APIs just like other popular platforms (for example, OpenAI and similar API providers). The way our APIs work is not different from industry standards.
Securing API keys is always the responsibility of the person using them—this applies to all APIs. Keys must be stored safely and not exposed publicly.
The domain whitelisting feature was added purely as a courtesy, to offer an extra layer of protection. It is not meant to be the primary security mechanism, and no API provider relies on domain checks alone for security.

2. “Zero-code” and authentication.
Our goal is to reduce complexity, not remove responsibility. . We are already working on built-in user authentication and will be releasing it soon.

3. SQL usage
SQL is provided only for modifying the database structure, not for editing data. This is clearly documented. Data operations are expected to be done through the APIs. Using the product outside its intended design will naturally feel restrictive.

4. Domain validation
We haven’t seen issues with adding valid domains so far, but this was never reported to support. We’re always happy to investigate when issues are shared with us.

In summary, the platform is production-ready when used as designed, following the same security practices required by any API-based service. We appreciate feedback, but the core issue here appears to be expectations and configuration—not hidden limitations.

If you need help or want to discuss improvements constructively, our support team is always available.

Thanks.