Routes

Summary

All route patterns the 2Wee client uses. Your server must implement these routes and return the expected JSON.

Entry points

The client knows two hardcoded paths (relative to the base URL):

Path	Purpose
/menu/main	Main menu (fetched on startup)
/auth/login	Login form (fetched on 401)

All other URLs come from the server — in actions, on_select, lookup.endpoint, menu item URLs, etc. The client does not construct them.

Standard routes

Pattern	Method	Request body	Response	Purpose
/menu/{menu_id}	GET	—	ScreenContract (Menu)	Menu screen
/screen/{resource}_list	GET	—	ScreenContract (List)	List view
/screen/{resource}_card/{id}	GET	—	ScreenContract (Card)	Card view
/screen/{resource}_card/new	GET	—	ScreenContract (Card)	Empty card for creation
/screen/{resource}_card/new	POST	SaveChangeset	ScreenContract (Card)	Create record
/screen/{resource}_card/{id}/save	POST	SaveChangeset	ScreenContract (Card)	Save changes
/screen/{resource}_card/{id}/delete	POST	DeleteRequest	ScreenContract (List)	Delete record

Grid routes

Pattern	Method	Request body	Response	Purpose
/screen/{grid_id}	GET	—	ScreenContract (Grid)	Grid screen
/screen/{grid_id}/save	POST	SaveChangeset	ScreenContract (Grid)	Save grid data

Lookup and validation routes

Pattern	Method	Request body	Response	Purpose
/lookup/{field_id}	GET	—	ScreenContract (List)	Lookup list for a field
/validate/{field_id}/{value}	GET	—	ValidateResponse	Blur validation
/drilldown/{field_id}/{key}	GET	—	ScreenContract	Drill-down

Action routes

Pattern	Method	Request body	Response	Purpose
/action/{resource}/{id}/{action_id}	POST	ActionRequest	ActionResponse	Execute action

Action endpoints are defined by the server in screen_actions[].endpoint. The patterns above are conventions — use any URL structure. See Screen Actions for details.

Authentication routes

Pattern	Method	Auth required	Request body	Response	Purpose
/auth/login	GET	No	—	ScreenContract (Card)	Login form
/auth/login	POST	No	AuthRequest	AuthResponse	Submit credentials

Query parameters

Parameter	Used on	Purpose
?query=text	List and lookup GETs	Search/filter rows server-side
?selected=value	Lookup GETs	Current field value for pre-selection positioning
?{param}={value}	Lookup and validate GETs	Context parameters from lookup.context definitions

?query=

The client sends search queries on list and full-screen lookup screens. Your server should filter rows and return only matching results.

GET /screen/customer_list?query=cannon
GET /lookup/customer_no?query=cannon

Modal lookups (display: "modal") do not use ?query= — the client filters locally.

Context parameters

When a lookup has a context array, the client reads the referenced field/column values and appends them as query parameters:

GET /lookup/no?type=Resource
GET /validate/no/8100?type=Resource
GET /lookup/post_code?country_code=FO

See Lookups — Context-dependent lookups for details.

URL architecture

The client takes a base URL (e.g., http://2wee.test/terminal).

• Entry points use the base URL: {base_url}/menu/main
• All other paths from the server are absolute (from the host root)
• The client resolves them by prepending only the scheme and host

Example with prefix:

• Base URL: http://2wee.test/terminal
• Client hits: http://2wee.test/terminal/menu/main
• Server returns paths like: /terminal/screen/customer_list
• Client resolves: http://2wee.test + /terminal/screen/customer_list

Example without prefix:

• Base URL: http://localhost:3000
• Client hits: http://localhost:3000/menu/main
• Server returns paths like: /screen/customer_list
• Client resolves: http://localhost:3000 + /screen/customer_list

Your server controls its own URL structure. The client follows it.

Naming conventions

These route patterns are conventions, not requirements. You can use any URL structure. The only hard requirement is:

1. /menu/main exists (client entry point)
2. /auth/login exists if authentication is enabled
3. All other URLs you return in your JSON are valid and return the expected response types