EmployeesAssign a normal working time to an employee

Assign a normal working time to an employee

Puts an employee on a normal working time (working-hour norm) from a given date, past or future.

Adds an entry to the employee's working-norm history: "from StartsAt, this employee works NormalWorkingTimeId". Effective-date semantics (the integrator-critical part): - Only the date of StartsAt counts. The entry runs from that date until the day before the next entry. - The new entry REPLACES every history entry that starts on or after the same date: those entries are marked obsolete (kept in the table, no longer in force). Assigning norm C from 1 March to an employee who had A since January and a scheduled change to B from 1 May leaves A (Jan - 28 Feb) and C (from 1 March) — the May change to B is gone. There is never an overlap; the latest call wins for its date onwards. - Backdating is allowed without limit and without any check against submitted, approved or payroll-exported periods. The employee's daily expected hours and flex norm postings are regenerated from the effective date (or the employment / calculation start date, if later), so flex balances of past weeks change retroactively. - StartsAt today or earlier: the employee's current norm switches immediately. - There is no delete: to undo, assign the previous norm again with the same StartsAt.

Use it to:

  • HR system pushes a contract change (e.g. 37 h to 30 h per week) with its effective date.
  • Schedule a future reduction of working hours (parental leave, part-time arrangement).

Not for:

  • Correcting a past norm when the affected weeks have been paid — the API recalculates flex silently; agree a process with payroll first.
  • Reading an employee's norm history — no REST v1 operation returns it.

Behaviour:

  • Idempotent.
  • Same effective state on a repeat, but each call writes a new history row, obsoletes the previous identical one, raises the events and triggers the recalculation again.
  • Safe to retry.
  • Duplicates: A repeat call supersedes the previous identical entry (see idempotent_detail).
  • Side effect: Resource Planner capacity of the employee is updated.
  • On failure: None expected: both checks run before the first write. If a later history update or the profile update fails, rows already written stay (no transaction around the loop).

Call first: GET /v1/normal-working-time, GET /v1/user

Next: GET /v1/employee-projection/get-in-period

See also: PUT /v1/user

Not yet documented: behaviour → side effects; behaviour → side effects on failure; examples (success).

curl -X POST "https://app3.timelog.com/your-account/api/v1/normal-working-time/assign-to-employee" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
  "UserId": 123,
  "NormalWorkingTimeId": 123,
  "StartsAt": "2024-12-25T10:00:00Z"
}'
{}
POST
/v1/normal-working-time/assign-to-employee
POST
Base URLstring

Target server for requests. Edit to use your own host.

Bearer Token
Bearer Tokenstring
Required

OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp). The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user. > Not yet documented: how to obtain a token. > Not yet documented: token lifetime.

OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp). The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user. > Not yet documented: how to obtain a token. > Not yet documented: token lifetime.
Content-Typestring
Required

The media type of the request body

Options: application/json
UserIdinteger
Required

User ID of the employee whose norm changes. Only existence is checked — not the active flag in the C# path, and not who the caller may edit. Refers to UserRead.UserID. Look up valid values with GET /v1/user. - 0, omitted or not an existing user — 500 Code 102, ErrorCode 37040 "No user with UserID: {0} exist" (captured for an empty body). - inactive user — Expected to be accepted: the existence check tests for null only. > Not yet documented: behaviour.

Format: int32
NormalWorkingTimeIdinteger
Required

NormalWorkingTimeID of the norm to put the employee on (from GET /v1/normal-working-time). Must be active. Refers to NormalWorkingTimeRead.NormalWorkingTimeID. Look up valid values with GET /v1/normal-working-time. - norm exists but IsActive is false — 500 Code 102, ErrorCode 37922 "Normal working time with ID:{0} is not active". Valid values come from GET /v1/normal-working-time. > Not yet documented: behaviour.

Format: int32
StartsAtstring
Required

First day the norm applies (inclusive). Only the date is used; any time part is dropped. Past, today and future dates are all accepted — there is no lower bound and no check against approved, closed or payroll-exported periods. The new entry supersedes every history entry starting on or after this date. Date only — no time component. - Projections from that date are regenerated now. - omitted — Binds to 0001-01-01. > Not yet documented: behaviour.

Format: date-time
Request Preview
Response

Response will appear here after sending the request

Authentication

header
Authorizationstring
Required

Bearer token. OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp).

The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user.

Not yet documented: how to obtain a token.

Not yet documented: token lifetime.

Body

application/json
UserIdinteger
Required

User ID of the employee whose norm changes. Only existence is checked — not the active flag in the C# path, and not who the caller may edit.

Refers to UserRead.UserID. Look up valid values with GET /v1/user.

  • 0, omitted or not an existing user — 500 Code 102, ErrorCode 37040 "No user with UserID: {0} exist" (captured for an empty body).

  • inactive user — Expected to be accepted: the existence check tests for null only.

Not yet documented: behaviour.

NormalWorkingTimeIdinteger
Required

NormalWorkingTimeID of the norm to put the employee on (from GET /v1/normal-working-time). Must be active.

Refers to NormalWorkingTimeRead.NormalWorkingTimeID. Look up valid values with GET /v1/normal-working-time.

  • norm exists but IsActive is false — 500 Code 102, ErrorCode 37922 "Normal working time with ID:{0} is not active".

Valid values come from GET /v1/normal-working-time.

Not yet documented: behaviour.

StartsAtstring
Required

First day the norm applies (inclusive). Only the date is used; any time part is dropped. Past, today and future dates are all accepted — there is no lower bound and no check against approved, closed or payroll-exported periods. The new entry supersedes every history entry starting on or after this date.

Date only — no time component.

  • Projections from that date are regenerated now.

  • omitted — Binds to 0001-01-01.

Not yet documented: behaviour.

Responses

Success without content: HTTP 204 with an empty body. HTTP 200 with an empty body (Ok()). Nothing to read back: no REST v1 operation returns an employee's norm history.