API Reference

The Moria API is a versioned HTTP/JSON API serving the mobile and web frontends. Every endpoint is prefixed with /v1. Authenticated endpoints accept a bearer JWT in the Authorization header or a access_token cookie.

Conventions

• Base URL — {HOST}/v1 (global prefix in main.ts).
• Auth — Bearer JWT (Authorization: Bearer <jwt>) or cookie access_token (httpOnly).
• Content-Type — application/json for everything except file uploads (multipart/form-data on /v1/file-manager/*).
• Success envelope — global ResponseInterceptor wraps the controller return as { status, statusCode, message, data, lang }. status is always "success" for 2xx; lang echoes the resolved response locale (en/id/ar).
• Error envelope — { message: string | string[], statusCode: number, error: string }.
• Validation — global ValidationPipe with whitelist: true, forbidNonWhitelisted: true, transform: true. Unknown fields are rejected with 400.
• Client type — a handful of read endpoints return a different data shape per x-client-type header (web vs mobile). See Client types below.

Client types (web vs mobile)

A subset of read endpoints branch their response data on an optional x-client-type request header:

• When the header is absent it defaults to mobile; any value other than web/mobile returns 400.
• x-client-type: mobile (default) → the raw entity shape: flat audit columns (created_at, created_by, updated_at, updated_by, deleted_by), foreign-key ids (*_id), and the stored field values as-is.
• x-client-type: web → a formatted shape produced by ResponseFormatter: audit fields are nested as created/updated/deleted objects { at, by: { id, first_name, last_name } }, and relations are replaced by hand-picked nested objects (e.g. account, organization, manager, customization, attached documents). Web clients must send x-client-type: web to receive this shape.

The envelope (status/statusCode/message/lang) and the pagination wrapper ({ limit, count, currentPage, totalPages, <collection> }) are identical across both clients — only the per-record shape inside data differs.

Endpoints affected (list + detail reads): Users, Saving Goals, Saving Circles, Charitable Cause, Commodity Financing. Each page shows the concrete web and mobile payloads.

Modules

#	Module	Endpoints	Scope
01	Authentication	2	Basic login / logout
02	Onboarding	7	Organization registration + OTP invite flow
03	Organizations	5	Organization CRUD
04	Users	8	User profile + demographic queries
05	Accounts	6	E-wallet accounts + transfers
06	ACL	10	Role & permission management (admin web)
07	Activity Log	2	User activity audit trail
08	File Manager	8	Presigned read/delete + storage utilities
09	Document	13	User documents + organization official documents
10	Saving Goals	8	Scheduled savings with targets
11	Saving Circles	8	Arisan / rotating savings
12	Charitable Cause	10	Campaign donations (wakaf, sedekah)
13	Commodity Financing	9	Murabahah commodity financing
14	Investments	14	Investment products (sukuk, mutual funds)
15	Takaful	9	Sharia insurance
16	Withdrawal	1	Withdraw to bank account
17	Payments	2	Pay bills from balance
18	Payment Gateway	3	Top-up via Bisabiller/Amdigipay
19	Transactions	5	Cross-product transaction history
20	Cards	10	Issued cards + linked cards
21	Category	5	Master category data
22	Location	4	Address CRUD
23	Settings	5	Global app settings
24	Customization	4	Per-organization theme/branding
25	Search	3	Cross-product search
26	Security	6	Change password, 2FA
27	Pools	6	Internal liquidity pools
28	Partner API	4	API keys for B2B integrators
29	Health	7	Uptime probe + maintenance
30	Open-Loop Wallet	12	Per-user wallet — top-up VA, disbursement, QRIS, e-wallet cash-out (Singapay)

Total: 30 modules · 196 endpoints.