FLOW LGX · PART 5 · FEBRUARY 2026

Flow LGX, part 5: sign-in, one-time codes and connecting the APIs

February 2026 was the month the dashboards stopped being pictures and started showing real data. That meant two things: a complete sign-in journey, and a clean way for every screen to talk to the server.

About this project

Month by month, how a logistics platform for a Toronto client went from a simple brief to a live, multi-company SaaS product.

In short

Users register, sign in and reset passwords with one-time email codes, then land on their own home page. Data loading was tuned so busy dashboards stay fast and never save anything twice.

The sign-in journey, end to end

Sign-in is the first impression of any platform and the place users get stuck most often. Flow LGX supports registration, sign-in, forgotten password, a one-time code sent by email, and password reset. Each screen has clear validation — names without leading spaces, real email formats, strong passwords — so problems are caught before a request is sent.

After sign-in, the user’s role decides where they land. A dispatcher goes straight to the dispatch area; a customer goes to their own home page. Nobody sees a generic dashboard and has to find their way.

API modules by role

Calls to the server are grouped the same way as pages: one module per role — super admin, admin, staff, dispatcher, distributor, vendor, direct customer — plus shared and public modules for things everyone uses, like notifications or the public carrier sign-up. A developer looking for “the call that loads warehouse inbound work” knows exactly which folder to open.

All requests go through one HTTP client that adds the user’s access token and handles expired sessions in one place (the next problem-solved post explains how).

Caching rules that suit operations

TanStack Query handles fetching and caching. We tuned its defaults for an operations dashboard rather than leaving them generic:

  • Data is treated as fresh for five minutes, so moving between pages does not re-download the same lists.
  • Failed reads are retried once; failed writes are not retried automatically, so a “create invoice” never runs twice by accident.
  • Lists are not refetched every time the browser tab regains focus — on busy desks that caused needless reloads.
  • After a change, only the affected queries are refreshed, so the table you are looking at updates without a full page reload.

What we shipped

  • Register, sign in, forgotten password, one-time email code and reset password
  • Role-based landing pages after sign-in
  • API modules organised by role, plus shared and public modules
  • One HTTP client with central token handling
  • Query caching tuned for operations: 5-minute freshness, safe retries

Lesson learned

Never retry a write automatically. Reads can be repeated safely; a second “create” is a duplicate invoice.