Invoice Ninja's Portal Is Not the Staff Console

Invoice Ninja offers a staff-facing administration interface, a client portal, and an API, each serving distinct users with different permission levels. While an inventory can identify where an instance exists, it cannot determine which portal paths are public or which staff accounts can view all company records. On October 30, 2026, ZoomEye used sub_type=all, page 1, and page size 1 parameters in count-only queries for app=Invoice Ninja, revealing no results.

The title query returned 4,051, indicating multiple visible page titles. This distinction in results is crucial for understanding where the system's boundaries lie. The product's user guide delineates separate user logins and permission sets, with bookkeepers potentially receiving access to payments and reports without client-edit rights.

The system also documents user management, invitations, and company membership. When a person is removed from a company, their data should be deleted, but the account might remain accessible for another company. To ensure security, staff should have two-factor authentication enabled. The API tokens and client-portal sessions have different lifetimes and recovery methods, underscoring that MFA on a browser login does not automatically protect a leaked API token.

The client portal is designed to display a client's invoices, payments, statements, subscriptions, and saved payment methods. It should not allow one client to read another's invoice or download URL. The API documentation specifies authentication using API secrets or tokens, returning user permission information. Each integration must have a distinct user and scope; staff owners' secrets must not be reused in public integrations or committed to deployment repositories.

The self-host installation includes a web stack and background jobs, with the maintenance endpoint, storage directory, or queue dashboard potentially not sharing the portal's login boundary. All exposed hostnames should be inventoried, not just the main application URL. A test plan involves creating two test companies and one user in each, verifying invoice and client visibility through the UI, repeating with API requests and direct file downloads, removing a user from one company and retesting, revoking a test API token and confirming denial, and inspecting public listeners for the portal, staff console, and API.

Synthetic invoice data should be used, avoiding real payment methods or customer email addresses. The operational value lies in determining whether the portal exposes only the intended client's data and whether staff permissions persist through company or role changes. A global count aids in identifying the product class, while local membership and token tests reveal whether the boundary functions correctly.