Invoice Ninja combines an administrative billing application with a client portal and an API. The portal is intentionally reachable by customers. The API is intended for automation. Treating both as one web application hides the separate authorization decisions that protect invoices, contacts, payment tokens, and company settings.
A ZoomEye SDK count-only query on November 2, 2026 returned 0 matches for app="Invoice Ninja" and 4,049 for title="Invoice Ninja" using sub_type=all, page 1, and page size 1. The combined title="Invoice Ninja" && http.body="Invoice Ninja" query returned 3,964. The body-only query returned 4,579.
The API documentation uses API tokens and documents X-API-Token as the v5 request header. An API login response includes company-user fields such as permissions, owner and administrator status, and a portal URL. The client portal lets customers view documents, pay invoices, download statements, and update contact details. Those are different identities with different permitted actions.
A review should map them separately:
- 1.
Administrative users, their company membership, owner status, and permission strings.
- 2.
API tokens, their owners, intended integrations, storage locations, and rotation dates.
- 3.
Client contacts, portal invitations, password or magic-link behavior, and disabled accounts.
- 4.
Payment gateway tokens and the application's ability to charge a saved method.
- 5.
Public invoice links and whether a link grants access beyond the intended document.
A token with broad API permissions should not be stored in a public client-side application. A portal user should not be able to change company settings or another client's contact record by changing an identifier. Test object-level authorization with two client accounts. Test API permissions with a company user who is not an owner. Check whether a disabled portal user's existing session or payment token remains usable.
The 3,964 combined title-and-body matches are a useful candidate set, but they do not prove that a site is a live billing instance or that its portal is exposed. A page can be a documentation mirror, a marketing site, or a customized login. The security team should confirm ownership before testing.
Invoice Ninja's risk is concentrated in the relationship between company users, API tokens, client portal identities, and payment methods. A count of public pages can help find candidate deployments. The access review has to follow each identity to the documents and actions it can reach.
Query evidence
app="Invoice Ninja" returned 0 matches, title="Invoice Ninja" returned 4,049, http.body="Invoice Ninja" returned 4,579, and title="Invoice Ninja" && http.body="Invoice Ninja" returned 3,964. All queries used sub_type=all, page 1, and a page size of 1.