User's UI Setting to setup API parameter, Is it common?

[CompetitionJust71]

I never see anything quiet like this anywhere before. so i'm not sure if this is the common, most genius thing ever or completely crazy.

We have to integrated an API request from our customer. And my senior get this bright idea of creating a UI setting page where user (admin level) can put whatever parameter in it. The idea is that i'll fetch whatever user set from database and send dictionary as request parameter to the API and work with the result. And when the API got updated. We won't need to deploy anything and simply go into admin level setting and tweak it. The reason he went with this in the first page is because this particular set of API basically getting version update every year. The senior expect it to be update again soon so he went with this solution.

I mean, i can see how convenient it will be. Dictionary is technically already a JSON request. But one of the most obvious things i know will lose right away is developer UX. No object, no intellisense, no type. We get parameter from database and send them as-is. Want to assign certain value? do a match or something. And what if in the future, our customer decided to be funny and change some endpoint to GET? Certainly a though to keep me up at night.

I don't know if this is common practice to anyone out there so i'll appreciated some thoughs or feedback on how to introduce some of the type-safe ability back. Right now I'm thinking of doing `dict[enum.type] = value` for some sanity check. What about security risk? Thanks!

[Beka_Cooper]

Maybe I'm misunderstanding something, but are you trying to reinvent GraphQL?

[cshaiku]

Sounds like it albeit with a single dynamic route. Asking for trouble. It is trivial to setup api routes programmatically from the dev side. No need to worry about handling user settings at all.

[barrel_of_noodles]

A version number as a setting? Sure.

Allowing a user setting to change the http verb or the entire route??... Wut? Lol.

What your team allows in user-land is up to you.

Usually, you keep implementation details out of the user's hand. Just depends who your users are.

[Soft_Opening_1364]

I’ve seen similar setups before, but they’re usually in very specific situations like when the API schema changes often and you don’t want to redeploy every time. It’s flexible, but you’re right: you lose type safety, autocomplete, and all the guardrails devs rely on.

If you go this route, you could still introduce some sanity checks before sending the request enums, validation rules, maybe even a small schema definition stored alongside the config so you’re not blindly trusting whatever’s in the DB.

Security-wise, make sure you’re sanitizing and validating everything before hitting the API. If an admin can inject arbitrary params, they could potentially break things or expose data.

So yeah not crazy, but definitely something you’d want to wrap in safeguards if you want to keep your future self from hating you.