How TimeLet Works

Three surfaces write to one API. The dashboard only reads.

Three clients, one REST API, one activity stream.

#How the pieces connect

The dashboard has no direct path to either client.

┌───────────────────────────┐
│      Web Dashboard        │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│       TimeLet API        │
└─────────────┬─────────────┘
        ┌─────┴─────┐
        ▼           ▼
┌─────────────┐  ┌────────────────┐
│ Desktop App │  │Browser Extension│
└──────┬──────┘  └───────┬────────┘
       │                 │
       └────────┬────────┘
                ▼
       ┌────────────────┐
       │ Activity Data  │
       └────────────────┘

Neither client talks to the other. The desktop app knows nothing about tabs; the extension knows nothing about windows. Both write activities, and the dashboard aggregates whatever arrives.

#Desktop app

Samples the foreground window on an interval. When the process name changes, it closes the current activity and opens a new one, which is why switching applications produces two timeline rows instead of one.

#Browser extension

Resolves the active tab, matches the domain against the rule set, and reports it with a duration. Categories are resolved locally so tracking survives an offline period.

#What the dashboard sees

The dashboard never observes anything itself. It issues range queries, the API applies your category overrides, and classification happens at read time rather than on write.

PreviousIntroduction

NextAuthentication