API Reference

Warka's custom backend is a set of whitelisted Python methods in the cyber_zeb_erp app: 55 methods in cyber_zeb_erp/cyber_zeb_erp/api.py and 6 in cyber_zeb_erp/cyber_zeb_erp/careers.py, 61 in total. Each is reachable at /api/method/<dotted.path> and returns its result inside a {"message": ...} envelope. This reference groups the endpoints by module, gives the HTTP method, whether guests are allowed, the role guard enforced, the key parameters, and what each returns. The role model itself is documented in Security and RBAC; the doctypes behind these calls are in Data Model.

Role guards

Every protected method calls a _require_* guard as its first line. Each guard checks the caller's roles against a role set defined near the top of api.py:

The manager-tier guards (_require_hr_manager, _require_accounts_manager) deliberately exclude the plain user role so that a single junior account cannot, for example, approve its own leave, run payroll, or post a raw journal entry. This is segregation of duties enforced in code.

How to call it

Every whitelisted method is called through the Next.js proxy at /api/method/<method>, and the real return value is under the message key.

# GET (read), no body
curl "https://your-site.example.com/api/method/cyber_zeb_erp.api.get_finance_overview" \
  -H "Cookie: sid=<session>"

# POST (write), JSON body
curl -X POST "https://your-site.example.com/api/method/cyber_zeb_erp.api.create_sales_invoice" \
  -H "Content-Type: application/json" -H "Cookie: sid=<session>" \
  -d '{"customer":"Acme Corporation","items":"[{\"item\":\"Consulting\",\"qty\":1,\"rate\":1000}]","tax_rate":15}'

Both return the same envelope shape:

{ "message": { "name": "SINV-0001", "grand_total": 1150.0, "submitted": true, "warnings": [] } }

From the frontend

Components never build these URLs by hand. frontend/lib/frappe.ts provides frappeCall(method, body), which issues a GET when there is no body and a POST with a JSON body otherwise, then returns data.message. The cyber helper prefixes the app namespace so callers pass only the method name:

import { cyber } from "@/lib/frappe";

// GET
const overview = await cyber.call("get_finance_overview");

// POST, list parameters are JSON-encoded strings
const res = await cyber.call("create_sales_invoice", {
  customer: "Acme Corporation",
  items: JSON.stringify([{ item: "Consulting", qty: 1, rate: 1000 }]),
  tax_rate: 15,
});

The same module exposes frappeList, frappeGet, frappeCreate, frappeUpdate, and frappeDelete over ERPNext's REST resource API for plain doctype access, and a FrappeError that carries the HTTP status so a 403 can be rendered as an access-denied state.

List parameters (items, users, roles) are accepted as a JSON string or a native list; the server parses them defensively and rejects malformed payloads with a clear error rather than a 500. Dates are validated and turn bad input into a friendly message. Many create endpoints auto-create missing masters (a Customer, Supplier, Lead, or service Item) so a form never dead-ends on a missing record.

Account and profile

All require an authenticated session; sign-up helpers are guest-accessible.

Notes: avatars are validated so a user can only point their image at a file they can read (_validate_own_avatar_url), and uploads are capped at 2 MB and must be images. sign_up never grants an admin role and can be disabled entirely with the disable_signup site-config flag; it returns a generic message whether the email is taken or invalid so it cannot be used to enumerate accounts.

HR and Payroll

Payroll: the two-phase pattern

run_payroll reuses HRMS Payroll Entry logic end to end. HRMS switches slip creation and submission to background workers above 30 employees, so a synchronous request would time out on any real company. The endpoint therefore splits:

• Small runs (30 or fewer) return the finished result directly, with queued: false, the slip counts, and total net pay.
• Large runs return {queued: true, payroll_entry, employees}. The client then polls get_payroll_status until creation_complete, calls submit_payroll_slips, and polls again until complete.

const run = await cyber.call("run_payroll", { start_date, end_date });
if (run.queued) {
  // poll get_payroll_status until creation_complete, then:
  await cyber.call("submit_payroll_slips", { payroll_entry: run.payroll_entry });
  // poll get_payroll_status until complete
}

Lifecycle: onboarding and offboarding

start_onboarding auto-creates the Job Applicant and an accepted Job Offer it needs, then a draft Employee Onboarding seeded from a template. finish_boarding for onboarding creates the actual Employee record (using the real date of birth and gender HR supplies) and provisions a login; for offboarding it marks the employee Left, sets a relieving date, and disables their linked login while dropping active sessions. submit_doc is restricted to a fixed allowlist of submittable HR doctypes (Expense Claim, Shift Assignment, Salary Structure and its Assignment, Job Offer, Appraisal, Employee Onboarding, Employee Separation).

Administration: users and roles

Only roles in the fixed ASSIGNABLE_ROLES list can be granted, and only those are touched on edit, leaving system-internal roles intact. Admins cannot remove their own System Manager role or disable their own account, and the Administrator account cannot be edited or disabled through the console. Welcome emails are only attempted when outgoing mail is actually configured.

Finance

Notes: invoice endpoints accept either a multi-line items list or a single amount for backward compatibility, auto-create the party and any service items, and try to submit but survive a failed submit as a draft (returning a short submit_error). Requested tax is applied only when a tax account exists, otherwise the call succeeds with a warnings entry rather than silently under-taxing. record_invoice_payment uses ERPNext's standard payment-entry builder and validates that the invoice is submitted, not cancelled, and not overpaid. The financial statements translate ERPNext's raw FiscalYearError into a clear "no open fiscal year covers this range" message.

Business dashboard

The guard is the union of HR_ROLES, ACCOUNTS_ROLES, SELLING_ROLES, BUYING_ROLES, STOCK_ROLES, and PROJECT_ROLES, so any operational role can see the company-wide overview. The payload is cached per company for 60 seconds and every section is defensive, so a missing module never breaks the view.

Sales and CRM

The CRM screen (components/crm/crm-manager.tsx) reads and writes Customer, Contact, Issue, and Customer Group directly through the REST resource API rather than custom endpoints. Sales endpoints resolve a party by name or display name, creating a minimal Customer or Lead when it is new, which is what prevents "could not find party" errors when quoting a fresh lead.

Procurement

Purchase invoices are created through the shared create_purchase_invoice endpoint listed under Finance.

Inventory

Projects

Documents

share_file_with_users makes the file private and grants read-only access to the named users. Only the file's owner, a user with write access, or an administrator may change sharing, so no account can grant itself access to arbitrary private files.

Careers (public portal)

Defined in careers.py. The public read and apply endpoints allow guests; the HR controls require HR roles.

The public endpoints only ever expose published, not-yet-closed openings; salary ranges appear only when HR explicitly opted in. apply validates the email, enforces resume type (.pdf, .doc, .docx) and a 5 MB cap, stores the resume as a private File, and rejects duplicate applications. All free text is HTML-escaped or sanitized before storage. Applications land as Job Applicant records in the HR recruitment pipeline. See Configuration and Customization for how the public page is branded to the customer company.