Skip to main content
Authoritative catalog of the accounting service’s HTTP endpoints, grouped by controller. Every controller under src/accounting/controllers/ is listed with its base route and each route’s HTTP method, path, purpose and required permission slug.

How authorization is resolved

The global PermissionsGuard (src/auth/permissions.guard.ts) decides the required permission for each request in this order:
  1. Explicit @RequirePermissions(...) on the handler or controller class — the user needs any one of the listed slugs. These are shown verbatim below.
  2. Route-based inference (fallback when no decorator is present) — module:operation, where:
    • module comes from a longest-prefix match in ROUTE_TO_MODULE. For accounting: api/accounting/debts and api/accounting/account-defaults map to accounting-debts; everything else under api/accounting maps to the catch-all accounting module.
    • operation comes from the HTTP method: GET/HEAD -> read, POST -> create, PUT/PATCH -> update, DELETE -> delete.
So an undecorated GET api/accounting/accounts effectively requires accounting:read; an undecorated POST under the same base requires accounting:create, and so on. In the tables below, the Permission column shows the explicit decorator slug(s) when present, otherwise the inferred accounting:<op> (marked inferred).
Slug shorthand: PERMISSIONS.X.Y resolves to module:action via buildPermission, e.g. PERMISSIONS.ACCOUNTING_BILLS.CREATE = accounting-bills:create. The accounting modules are accounting, accounting-accounts, accounting-journal, accounting-bills, accounting-expenses, accounting-invoices, accounting-debts, accounting-payments, accounting-budgets, accounting-contacts, accounting-reports.
Most controllers also stack @UseGuards(TenantAuthGuard, AccountingWorkspaceGuard) (or the equivalent), which enforce tenant isolation and the workspaceId (accounting-book) scope on top of the permission check.

account-defaults.controller.ts

Base: api/accounting/account-defaults

accounts.controller.ts

Base: api/accounting/accounts — no per-route @RequirePermissions; all inferred from route+method (accounting:<op>).

accounting-audit.controller.ts

Base: api/accounting/audit-events

accounting-bridge.controller.ts

Base: accounting/bridge (note: not under api/accounting). Service-to- service posting bridge used by other products.

accounting-periods.controller.ts

Base: api/accounting/periods

bank-loans.controller.ts

Base: api/accounting/loans — inferred permissions.

bank-statement-lines.controller.ts

Base: api/accounting/bank-statement-lines

bank-reconciliations.controller.ts

Base: api/accounting/bank-reconciliations

bills.controller.ts

Base: api/accounting/bills — explicit @RequirePermissions on all mutations.

budgets.controller.ts

Base: api/accounting/budgets — inferred permissions.

categories.controller.ts

Base: api/accounting/categories

chart-import.controller.ts

Base: api/accounting/chart-import

contacts.controller.ts

Base: api/accounting/contacts

cost-centers.controller.ts

Base: api/accounting/cost-centers

debt-settings.controller.ts

Base: api/accounting/debt-settings

debts.controller.ts

Base: api/accounting/debts (maps to the accounting-debts module).

expense-claim-types.controller.ts

Base: api/accounting/expense-claim-types

expenses.controller.ts

Base: api/accounting/expenses — explicit @RequirePermissions on mutations.

financial-reports.controller.ts

Base: api/accounting/reports — no per-route @RequirePermissions; inferred.

integration.controller.ts

Base: api/accounting/integrations

invoices.controller.ts

Base: api/accounting/invoices — explicit @RequirePermissions on mutations.

journal.controller.ts

Base: api/accounting/journal-entries — explicit @RequirePermissions on mutations.

journal-entry-template.controller.ts

Base: api/accounting/journal-entries/templates

opening-balances.controller.ts

Base: api/accounting/opening-balances

payment-reconciliation.controller.ts

Base: api/accounting/payment-reconciliation

payment-term.controller.ts

Base: api/accounting/payment-terms

payments.controller.ts

Base: api/accounting/payments — explicit @RequirePermissions on mutations.

period-reopen.controller.ts

Base: api/accounting/accounting-periods (period-reopen request workflow).

petty-cash.controller.ts

Base: api/accounting/petty-cash Base: api/accounting/print-settings

quotations.controller.ts

Base: api/accounting/quotations

recurring-transactions.controller.ts

Base: api/accounting/recurring-transactions

reminder-settings.controller.ts

Base: api/accounting/reminder-settings

report-presets.controller.ts

Base: api/accounting/reports/presets — no per-route @RequirePermissions; inferred.

tax-code.controller.ts

Base: api/accounting/tax-codes

terms-templates.controller.ts

Base: api/accounting/terms-templates

withholding-code.controller.ts

Base: api/accounting/withholding-codes

workspace-settings.controller.ts

Base: api/accounting/workspace-settings

year-end-close.controller.ts

Base: api/accounting/year-end-close

Notes & caveats

  • Inferred permissions are effective, not declared. Endpoints marked (inferred) carry no @RequirePermissions decorator; the permission shown is what the global PermissionsGuard computes from the route base + HTTP method. If ROUTE_TO_MODULE changes, these change with it. Confirm against src/auth/permissions.guard.ts when precision matters.
  • Platform admins bypass the permission check entirely (Admin, SuperAdmin, Super Admin — exact, suffix-free role names only).
  • accounting/bridge is the one accounting controller not under api/accounting; its four POST intents carry explicit accounting:write, while the source-links GET has no decorator and the base path is not in ROUTE_TO_MODULE (verify its effective guard before relying on it).
  • Several controllers also enforce ownership/scope inside the service beyond the guard (e.g. report presets are owner-only for mutations; bills/invoices run a maker-checker doc-status state machine). Those checks are documented in the respective service docs, not encoded in the permission slug.