absentify REST API introduction and overview

​

Welcome to the absentify developer documentation

Welcome to the developer documentation for absentify! This guide provides everything you need to start using the absentify API for efficient management of absence requests, approvals, and real-time integrations via webhooks.

​

Choose your starting point

---

​

Managing allowances through the API

Allowances are driven by allowance rules. A rule defines how much is granted per cycle, when the allowance year starts, and what happens to unused allowance. Every rule belongs to an allowance type, the balance that leave types draw from. Employees are connected to a rule through a rule assignment with a validity period, and individual corrections are recorded as adjustments on top of the rule. The Allowance Management endpoints follow that model: A few things to know before you integrate:

• All Allowance Management endpoints require an admin API key. The exceptions are the read-only GET /allowance-types, GET /allowance-types/{id}, and GET /members/{member_id}/allowances, which a manager key can also call for the members it is allowed to see.
• GET /allowance-types returns the ids that every rule, rule assignment, adjustment, and balance endpoint expects as allowance_type_id.
• Date-only fields (rule_start_date, rule_end_date, accrual_anchor_date, adjustment date and expiry_date) must be sent as YYYY-MM-DD. Values that are not real calendar dates, such as 2026-02-30, are rejected.
• On a rule assignment, rule_start_date is the first day the rule applies and rule_end_date is the last day it applies. To cover a member through August 31, 2026, send 2026-08-31. Send null for an open-ended assignment. GET returns the same convention, so a value you read can be sent straight back in a PATCH.
• On PATCH /rule-assignments/{id}, omit rule_end_date to leave the current end date unchanged, and send null to make the assignment open-ended.
• Amounts follow the allowance type’s unit: days for day-based types, minutes for hour-based types.
• proration_basis controls how a partial year is calculated on yearly rules. month counts whole months and prorates the started month by day; day is calendar-day exact. It defaults to month and is ignored for monthly and bi-weekly cycles.
• DELETE /rules/{id} requires reassign_to whenever members are still assigned to the rule.
• Rule changes accept an optional reason that is stored in the audit trail. Creating, updating, or deleting a rule assignment requires a reason of 3–500 characters; leading and trailing whitespace is ignored, and whitespace-only values are rejected.

​

Managing allowance types

• POST /allowance-types creates a type without any rule, so nothing accrues on it until you add one through POST /allowance-types/{allowance_type_id}/rules. How many allowance types a workspace may have depends on its plan.
• allowance_unit is days or hours and cannot be changed after the type exists. On an hours type, every amount in the API is expressed in minutes.
• PATCH /allowance-types/{id} applies only the fields you send. Omit a field to leave its current value untouched, so two integrations changing different fields cannot overwrite each other. Sending translations replaces the stored translations; omit the field to keep them.
• In responses, name is translated into the language of the API key owner where a translation exists, while default_name is always the stored name.
• DELETE /allowance-types/{id} is rejected while leave types still draw from the type, while it is any member’s default type, while it still has rules, and for the last remaining type of the workspace.
• POST /allowance-types/reorder sets the order the types appear in throughout the app and in GET /allowance-types. Send every id of the workspace. An id you leave out keeps its old position, which makes the resulting order ambiguous.
• PUT /allowance-types/{allowance_type_id}/default-rule points the organisation default at another rule. New members are put on it unless their department has a default rule of its own; members who already exist are not moved. The rule must be an active, shared rule of that allowance type.

​

Moving members between rules

• POST /members/{member_id}/rule-change moves a member to another rule. It ends the current assignment on valid_from and starts the new rule the same day, in one transaction, so there is neither a gap nor an overlap and the move is recorded as a single audit entry. Prefer it over deleting and recreating an assignment. Pass the assignment you are replacing as current_assignment_id, taken from GET /members/{member_id}/rule-assignments.
• POST /members/{member_id}/manual-rule takes a member off automatic accrual for one allowance type from valid_from on. Nothing accrues afterwards, and the balance is whatever you set through adjustments. Pass the member’s active assignment as current_assignment_id and it is ended in the same transaction; without it, an assignment that overlaps valid_from makes the call fail. Send null when the member has no assignment.
• On both endpoints, valid_from is the first day covered and valid_until is the last day covered, in YYYY-MM-DD format, the same convention as rule_end_date. Send null for an open-ended assignment. Both require a reason of 3–500 characters.
• GET /rules/{rule_id}/members lists the members whose assignment to a rule has not ended yet. limit caps how many are returned (1–50, default 10) and total always counts all of them. There is no offset, so treat the list as a preview rather than full pagination.

​

Reading balances and history

• GET /members/{member_id}/allowances returns every fiscal year of every allowance type the member can use, oldest first, and is the read side of the deprecated PUT endpoint below. allowance is the effective entitlement and equals rule_allowance plus adjustments: the part the rule granted, plus the part that came from manual adjustments. Allowance types that are switched off for the member are left out.
• GET /members/{member_id}/allowance-breakdown explains a single fiscal year the way the ledger does in the app: the rule that was active, what accrued month by month, what was carried over, what expired, and which requests were booked out of it. When legacy_unmigrated or no_allowance_for_year is true, there is nothing to explain and the remaining fields are empty.
• POST /allowances/{id}/revert-carryover-override drops a carry-over that was set by hand and recomputes the member’s allowances before the response returns. The id is the member_allowance_id from the breakdown, and the brought_forward it returns is the value from before the revert. Read the allowances again for the recomputed figure.
• The four audit endpoints answer different questions: GET /rules/{rule_id}/audit-log for one rule and its assignments, GET /allowance-types/{allowance_type_id}/audit-log for every rule of a type, GET /members/{member_id}/rule-audit-log for which rules a member was put on or moved to, and GET /members/{member_id}/allowance-audit-log for hand-set balances, carry-over overrides, and deleted adjustments. All return the newest entries first.
• On the rule and allowance-type logs, take controls how many entries you get (1–200, default 100); the member allowance history returns at most the 200 newest entries. The changes object depends on event_type: a rule edit carries { field: { from, to } } pairs, a rule change carries from_rule_id and to_rule_id.
• A member moving to another rule is filed under the rule they moved to, with the previous rule in changes.from_rule_id. Rules that were deleted keep their history, and the allowance-type audit log is the only place those entries can still be read.

---