[yashmaistry]

That's true, it doesn't make it obvious.

We handle security in a few ways;

- Clients are initialised with Key & ID - We advocate for keys to not be hardcoded

- The key is used for request encryption and are never sent to the server. Request hashes are also used to make sure Man In the Middle Attacks are avoided

- Custom Auth Tokens can be sent with requests - On the server side we use your provided auth callback to ensure it is valid

What do you think about the steps we take? Tokens are really important because they offer another layer of protection

[bpicolo]

> Clients are initialised with Key & ID - We advocate for keys to not be hardcoded

They're public facing (used by clients), so it doesn't really matter if they're hardcoded or not. I can rip them out of the dom/api calls/whatever.

For the second part, https covers you alone.

Auth tokens may start to pick at the puzzle, but at that point it's not obvious what I'm gaining if I have to bake custom authorization and authentication somewhere in any case?

You have a tough battle here - the security risk is huge. I don't personally see a value add yet, especially with Twilio/Stripe who have some of the lowest cost integration in the industry.

Not impossible to succeed in the arena, but the level of abstraction doesn't feel like the right fit yet

[yashmaistry]

I see where you are coming from As it stands, it only solves a niche problem.

We want to help new startups, who are both looking to get their MVP build faster and are looking for no code/ low code options.

It will take time to build out a product for the larger community but for now we are looking to small a problem.

Thanks for your feedback