I am sure that the aboce will be most welcome by develpopers, which I am not but will be you be introducing the ability to have:
either to admins at the same time so that the developer can have access to all aspects of QF rather than me having to give up admin rights and transfer them over to the developer, not a comfortable feeling.
or a developer level of user where the developer will have access to all aspects of QF without being the admin.
I hope so!
Hi @3Unique
Thanks for your post!
Just for me to understand the use case of this, is there a particular scenario (or scenarios) where a developer would need access to various parts of the account (that also require admin access)?
Dear Mathew
Thank you for your quick respond to this request.
I asked my developer, who I have worked with for 25 years and has recently used your API on a new project of mine to write a few words.
One of the main reasons is “Account Settings // 3rd Party Integration // Webhooks”
Also: “Account Settings // 3rd Party Integration // Developer Dashboard”
Rather than being a “Developer Access”, the need is more a “Technical Access” or “Technical Admin”
The “FULL Administrator” is really “someone who needs access to all company finances and settings.
However, they are often not the same person that manages “technical integration and connectivity to 3rd Party systems, IT-configurations.
At the moment, the lack of “permission difference” means that the company-owner has to transfer “full control” over to their IT-Team (which might even be outsourced), and then “hope” that they’ll transfer control back again.
More choice of “levels of permission” and “who can do what” would allow the necessary access.
There would still be “only one” account-owner, but it would mean that the IT-Team could have access to necessary features without having to ask the owner to transfer “full control” each time a change is needed.
——-
I would add from my perspective (though not in the case of this developer) that handing over the admin to a third party:
We both may have misunderstood this area but my developer feels it worth mentioning.
I also asked Perplexity and this is the AI’s view:
QuickFile currently requires you to be logged in as the admin to register an app and generate API credentials, so as things stand a normal user account cannot independently build integrations — and in my view, that’s a real design gap worth flagging, though there are reasonable workarounds.
How QuickFile Handles This Today
The API documentation is explicit that you must register your application “within your main QuickFile developer account” to obtain an ApplicationID and API key, and this registration happens under Account Settings → 3rd Party Integration → API. When a QuickFile support team member was asked directly whether a developer could get sandbox/API access without being logged in as the system administrator, the answer was blunt: “there isn’t a way of allowing this”.
The only workaround QuickFile officially offers is spinning up a separate account purely for API testing purposes.
My Opinion
I don’t think this is good practice from a security standpoint, and QuickFile’s own architecture works against the principle of least privilege here.
A developer building an integration typically needs create/read/update access to specific endpoints (invoices, contacts, bank feeds, etc.) — not the ability to delete the account, manage billing, or reassign other users’ permissions, which is what bundling API access with admin status effectively grants them.
Other platforms e.g. Salesforce lets you create dedicated “integration-only” user licenses restricted purely to API scope, and Open WebUI lets admins grant a specific “API Keys” permission to a non-admin group without handing over full admin rights.
QuickFile’s all-or-nothing approach means you either trust a developer with full admin control of your books, or you create an entirely separate throwaway account just to issue API credentials — neither is ideal.
Practical Implications for You
Given your work building admin backend systems and integrating with APIs (Sage, Delta Dore), if you commission a developer to build a QuickFile integration for your property management setup, you have three realistic options: make them a temporary admin, log in yourself to generate the ApplicationID and hand over just the App ID and API key, or set up a dummy account solely for their sandbox testing. The second option is generally the safer route in practice, since the API key/App ID pair itself is scoped to whatever specific permissions you configure for that app in the API registration form, even though creating that registration requires admin access in the first place. You could also raise this as a feature request on QuickFile’s community forum, since other users have flagged the same friction around wanting API access without full admin exposure.
Hope this helps.
Regards
Michael