But then give each client their own portal where they can only see their stuff (and maybe update tasks, upload documents, comment, etc.).
Has anyone built something like this with Custom Apps?
Or would I need to build an external frontend using the Fibery API? Because I have some client that don’t want to sign up on any other tool, Just sending a link of their portal and nothing else. No login to fibery or other tools
I’ve found that gating apps based on the viewer is pretty easy in Custom Apps, provided that that person is already in our Fibery environment and access has been planned accordingly.
This all depends on building the real boundaries in Fibery first: a dedicated space/DB structure (Client Portal / Client-facing entities) that only contains what’s safe for any client to see. Once the DB-level access is right, the app itself controls field-level exposure by simply not querying or rendering anything it doesn’t want a given viewer to see — but it has to be built on top of that same scoped access you used for the spaces and DBs.
I’ve used this method to build multiple apps for our teams that show only what’s relevant to their particular team, or even more narrowly—only their own personal assignments, calendar, documents.
Everything above assumes the client is actually in Fibery — logged in, with access planned for their role. An external frontend could be used to solve the login problem, but it does introduce complications.
Fibery API tokens are tied to the person who created them and carry that person’s full permissions — there’s no concept of “issue a token scoped to just Client X’s data.” So every call your external app makes to Fibery — whether it’s Client A checking their project or Client B uploading a file — goes through as the same one account, with that account’s full read/write access to everything it can touch. Fibery has no idea multiple different people are behind it; as far as the platform is concerned, it’s all just you.
Which means:
There’s no native audit trail per client. Every action lands in Fibery attributed to the token’s owner, not to the actual client who did it — if you need to know who touched what, you have to build and maintain that logging yourself, outside Fibery.
The security boundary moves entirely into your app. Fibery isn’t enforcing anything on this path — it trusts the token completely. Your app’s auth/filtering logic is the only thing standing between “anyone with a link” and full access to whatever that token can reach. A missed auth check, a leaked token, or a guessable client ID in a URL doesn’t just expose one client’s data — it potentially exposes all of it, since nothing on Fibery’s side is scoping the request.
So it comes down to which problem you actually need to solve. If your clients can live with a Fibery login, Custom Apps on scoped access get you a clean, gated portal with Fibery doing the enforcement. If they can’t, an external frontend gets you the no-login link, but you’re trading Fibery’s access model for one you build and maintain yourself.
I would also add that there is also a difference in user account licence costs. If you rely on Fibery permissions, with each client having their own account, then you are going to be paying for a licence for each of them, whereas an external front end with a single API token would support as many clients as you like (albeit with all the security boundary challenges already mentioned)
