Skip to main content
A collaborator’s activity rate is a timeline: an ordered set of non-overlapping periods, each covering a date range and carrying a rate and a few settings. Assigning a rate does not add a record — it makes that rate true over that range, and tipee reshapes the neighbouring periods accordingly.

Timelines

Read this first. How tipee merges, truncates, splits and deletes periods when you write to a timeline — including the two cases most often reported as bugs.
This page covers only what is specific to activity rates.

Assign activity rate

Make a rate true over a date range.

Unassign activity rate

Remove the rate over a date range.

Show activity rates

Read the resulting timeline.
Vocabulary. The API says activity rate; the tipee interface says contrat de taux (rate contract). They are the same object.

Identity fields

Two activity rate periods are identical — and therefore merge when adjacent or overlapping — when all seven of these values match: The comparison is on effective values. work_regime_id in particular may be omitted, in which case the regime is inherited along the chain collaborator → sector → site → instance. A period with an explicit regime and a period inheriting that same regime are identical, and will merge.
If a period with an explicit work_regime_id merges with a neighbour whose regime is inherited, the merged period is stored as inherited (work_regime: null). The effective regime is unchanged today, but the period is no longer pinned: if the sector, site or instance regime changes later, that period follows it.

Reading the timeline

resources.show-activity-rates returns the periods sorted by start date.
Periods have no id. A period is identified only by its date_range on a given resource_id. Do not store a tipee id for an activity rate period, and do not track a period across writes by identity — re-read the list and match on date_range. work_regime: null means inherited, not none. The response does not resolve the inheritance chain, so it does not tell you which regime actually applies. You can infer it from the shape of activity_rate_patterns: the non-null weekdays reflect the effective regime — a 42h/5-day regime yields five non-null weekdays, a 42h/4-day regime yields four. activity_rate_patterns is derived and read-only. It is average_rate spread evenly over the effective regime’s working days, and cannot be set through the API.

Creating a collaborator

A collaborator created without the additional_settings.activity_rate_contract block has no activity rate period at all — a clean starting state. The two creation paths do not share the same defaults: a period created through resources.create comes out with compensation_enabled: false, whereas resources.assign-activity-rate follows the instance configuration. Send compensation_enabled explicitly.