Invoice Ninja exposes a staff-facing administration interface, a client portal, and an API. Those surfaces serve different users and should not share the same assumptions about permissions. A product-level inventory can show where an instance appears; it cannot show which portal paths are public or which staff accounts can see every company record.

The count

On 2026-10-30, ZoomEye count-only queries used sub_type=all, page 1, and page size 1. app="Invoice Ninja" returned 0. title="Invoice Ninja" returned 4,051.

The zero app result is a fingerprint result, not a denial that self-hosted Invoice Ninja systems exist. The title result is a separate observation about visible page titles. The counts are useful for discovery and should be retained with their exact query scope.

Staff permissions

Invoice Ninja's user guide describes separate user logins and permission sets. A bookkeeper can receive access to payments and reports without receiving client-edit rights. The same guide documents user management, invitations, and company membership.

Review users by company and role. A person removed from a company should lose that company's data, but the account may remain available for another company. Confirm the membership change on the next login and with the API. Look for old invitations and service accounts that never completed onboarding.

Two-factor authentication should cover privileged staff. The basic settings documentation describes TOTP-based two-factor authentication. API tokens and client-portal sessions have different lifetimes and recovery paths, so MFA on a browser login does not automatically protect a leaked API token.

Portal and API boundaries

The client portal is intended to show a client's invoices, payments, statements, subscriptions, and saved payment methods. Test the portal with two test clients and confirm that one cannot read the other's invoice or download URL. Check whether a shared portal link can be forwarded beyond the intended client.

Invoice Ninja's API documentation describes authentication that uses API secrets or tokens and returns user permission information. Give each integration a defined user and scope. Do not reuse a staff owner's secret in a public integration or commit it to a deployment repository.

The self-host installation documentation covers the web stack and background jobs. A maintenance endpoint, a storage directory, or a queue dashboard may not share the portal's login boundary. Inventory all exposed hostnames, not only the main application URL.

A test plan

  1. 1.

    Create two test companies and one user in each.

  2. 2.

    Verify invoice and client visibility through the UI.

  3. 3.

    Repeat with API requests and direct file downloads.

  4. 4.

    Remove a user from one company and retest.

  5. 5.

    Revoke a test API token and confirm denial.

  6. 6.

    Inspect public listeners for the portal, staff console, and API.

Use synthetic invoice data. Do not test with a real payment method or a customer's email address.

Operational value

The security question is whether the portal exposes only the intended client's data and whether staff permissions survive a company or role change. A global count helps find the product class; local membership and token tests show whether the boundary works.

References