This document provides the official API documentation for the All Hours time tracking and workforce management system. The API enables developers to seamlessly integrate All Hours features into their own applications, allowing for automated time tracking, attendance management, and reporting. Currently our API supports TLS 1.3, with TLS 1.2 as the minimum supported version. All API endpoints and detailed query structures are provided on https://api4.allhours.com
\nAll responses to API requests are returned in JSON format.
\nThe HTTP request method (verb) you use defines the action you're performing:
\nGET: Used to retrieve data from All Hours.
POST: Used to create new records in your All Hours account.
PUT: Used to update a record in your All Hours account
DELETE: Used to delete a sprecific record of your choice
The API will return appropriate HTTP status codes based on the outcome of each request:
\n200 OK: The request was successful.
4XX Errors: Indicate an issue with the client's request (e.g., bad request, unauthorized access).
5XX Errors: Indicate a server-side issue on our end.
For any questions or support, please contact us at support@allhours.com.
\nThis section provides instructions on how to enable application integration through API calls for All Hours. The process involves accessing the settings, creating a new API key, and generating a Client ID and Client Secret for authentication. These credentials allow external tools to interact with the All Hours platform via API. Users can manage or revoke access by deleting API keys.
\nYou can visit the full detailed description on how to get the correct credentials here.
\nAll Hours API requires a valid API key to authenticate requests. To use the API, follow these steps to generate the necessary credentials and incorporate them into your Postman workspace:
\nGenerate API Key:
\nLog in to All Hours and navigate to Settings > Advanced.
\nClick on Create new API key and provide a name for the key.
\nAfter creation, you will receive a Client ID and Client Secret.
Authentication:
All Hours uses OAuth2 for authentication. In your API request, the Client ID and Client Secret will be required for authorization.
Postman Configuration:
\nIn Postman, go to the Authorization tab for the request.
Select OAuth 2.0 as the type.
Set the Grant Type to Client Credentials.
Input theClient ID and Client Secret in the relevant fields.
Add the token URL https://login.spica.com/connect/token
\nSend Requests:
Once the OAuth2 token is generated, include it in the header of each API call for authentication.
Ensure that the API key is kept secure. If compromised, delete the key immediately and generate a new one.
\n","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","toc":[{"content":"Overview","slug":"overview"},{"content":"Authorization","slug":"authorization"}],"owner":"34768727","collectionId":"4cb898fd-91f9-481a-8ac6-7304f31d995f","publishedId":"2sB2qi7HYr","public":true,"customColor":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"},"publishDate":"2025-06-03T06:16:32.000Z"},"item":[{"name":"Category Definitions","item":[{"name":"Retrieve Category Definitions","id":"8d4a79fc-e3da-453e-a508-c04d1b2fec43","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"auth":{"type":"oauth2","oauth2":{"basicConfig":[],"advancedConfig":[{"key":"tokenType","value":"This endpoint retrieves a list of category definitions. You can use the optional searchTerm query parameter to filter results based on a specific keyword. This is useful for narrowing down categories and improving search efficiency.
/api/v1/CategoryDefinitions200 OK - The request was successful, and a JSON response containing category data is returned.
400 Bad Request - The request was malformed. This could happen if the searchTerm parameter contains invalid characters or is improperly formatted.
This endpoint retrieves detailed information about a specific category definition by its unique identifier (id). It is useful for accessing information about a particular category.
/api/v1/CategoryDefinitions/{id}id is in a valid UUID format to avoid errors.200 OK - The category definition was successfully retrieved, and a JSON object containing the details is returned.
404 Not Found - No category definition was found for the specified id. This may occur if the id is invalid or does not exist.
The Category Definitions endpoint lets you manage categories efficiently using standard HTTP methods. You can retrieve, update, delete, list, and create category definitions. Fetch details of a specific category by ID, update its info, delete it, list all categories, or add new ones.
\nThis status determines whether a category is displayed as paid or unpaid within your program:
0 = Unpaid category
1 = Paid category
The Presence Status defines how a user associated with a specific category is displayed to others:
\n0 = Absent
1 = Present
2 = Break
3 = Work from Home
4 = In the Field
searchTermhttps://api4.allhours.com/api/v1/CategoryDefinitions?searchTerm=Physical presence\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available absences.This endpoint retrieves a list of absence definitions, which may include different types of absences (e.g., Sick Leave, Vacation). You can filter the results using a searchTerm to find specific absence.
/api/v1/AbsenceDefinitions200 OK - The absence definitions were successfully retrieved. The response will contain a JSON array of absence definitions.
400 Bad Request - The request is invalid, possibly due to incorrect query parameters.
This endpoint retrieves detailed information about a specific absence definition by its unique identifier (id). This is useful for accessing information about a particular type of absence, such as \"Sick Leave\" or \"Vacation\".
/api/v1/AbsenceDefinitions/{id}id is in a valid UUID format to avoid errors.200 OK - The absence definition was successfully retrieved, and a JSON object containing the details is returned.
404 Not Found - No absence definition found for the specified id. This may occur if the id is invalid or does not exist.
The AbsenceDefinitions endpoint provides a set of API operations for managing and retrieving types of AbsenceDefinitions within the system. These endpoints enable administrators and applications to define, manage, and access various types of absences, such as \"Sick Leave\" or \"Vacation,\" allowing for streamlined absence tracking and categorization within the organization.
\n0 = Whole Day Absence
1 = Half Day Absence starting at the begining of the shift
2 = Half Day Absence ending at the end of the shift
3 = Half Day Absence (start is not defined)
4 = Whole Day Absence with partial option
0 = No restriction (everybody can use this absence definition)
1 = Admin restriction (only admins have privilege of accessing this absence definition)
2 = Tag restriction (only people with a certain tag can use this absence definition)
searchTermhttps://api4.allhours.com/api/v1/AbsenceDefinitions?searchTerm=Study\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available absences.This endpoint retrieves employee absence records, with options to filter results by date range or serachTerm. By setting a start and/or end date, you can limit the records to a particular period. You can also use a keyword to refine the results based on employee names, absence reasons, or other details. This is ideal for tracking absences, generating reports, or analyzing absence trends in your organization.
/api/v1/Absences200 OK - The request was successful, and a JSON response containing absence data is returned.
400 Bad Request - The request was malformed. This may happen if the date format is incorrect or if there is an issue with the parameters provided.
This endpoint retrieves obfuscated records of employee absences, with certain data fields anonymized or partially hidden. You can filter results by specifying a start and/or end date and use a keyword to narrow down specific terms, such as employee identifiers or absence status, for more targeted results.
\n/api/v1/Absences/Obfuscated200 OK - The request was successful. Returns obfuscated absence data in JSON format.
400 Bad Request - The request is invalid, possibly due to incorrect date formatting or other issues with the query parameters.
This endpoint retrieves detailed information about a specific absence record by its unique identifier (id). It is useful for fetching individual absence details when you have the specific id of the absence record.
/api/v1/Absences/{id}200 OK - The request was successful, and a JSON response containing the absence record details is returned.
404 Not Found - The specified id does not correspond to any existing absence record. This may occur if the id is invalid or the record has been deleted.
This endpoint allows you to create a new absence record for an employee. You must provide a JSON payload with the necessary details, including the user’s ID, absence type, dates, and additional settings related to the absence.
\n/api/v1/AbsencesUserId (string, required): Unique identifier for the user.
Timestamp (datetime, required): The date and time of when the absence will be created.
AbsenceDefinitionId (string, required): The unique identifier for the type of absence.
Origin (integer, optional): Indicates the source of the request
OverrideHolidayAbsence (boolean, required): Indicates if the absence will override holiday or not.
If IsPartial is true, then PartialTimeFrom and PartialTimeTo fields are required.
201 Created – The absence record was successfully created. The response will contain a JSON object with the details of the newly created absence.
400 Bad Request - The request is invalid. This may occur if required fields are missing or data formats are incorrect.
This endpoint allows you to create multiple absence records in a single request. It is designed for batch processing, allowing you to submit several absence entries with shared or unique parameters. This is particularly useful for bulk updates or for recording multiple absences at once.
\n/api/v1/Absences/BulkUserId (string, required): Unique identifier for the user.
AbsenceDefinitionId (string, required): The unique identifier for the type of absence.
Origin (integer, optional): Indicates the source of the request
PeriodOptions (integer, required) : Specifies the options for the adjustment period.
PeriodFrom (datetime, required): Start date of the absence period
PeriodTo (datetime, required): End date of the absence period
OverrideHolidayAbsence (boolean, required): Indicates if the absence will override holiday or not.
If IsPartial is true, then PartialTimeFrom and PartialTimeTo fields are required.
201 Created - The absence records were successfully created. The response will contain a JSON object confirming the successful creation of the records.
400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
This endpoint allows you to update an existing absence record specified by its unique id. You need to provide a JSON payload containing the updated details for the absence record. This is useful for modifying the absence information, such as changing dates, adding comments, or adjusting partial absence times.
Endpoint: /api/v1/Absences/{id}
Idin the path should be the same as Id in the request bodyId (string, required) The unique identifier for the absence record being updated
UserId (string, required) The unique identifier for the user associated with this absence record.
Origin (integer, optional): Indicates the source of the request
Timestamp (datetime, required) The timestamp when the absence record is updated
AbsenceDefinitionId (string, required) The unique identifier for the type of absence (e.g., Sick Leave, Vacation...).
OverrideHolidayAbsence (boolean, required): Indicates if the absence will override holiday or not.
If IsPartial is true, then PartialTimeFrom and PartialTimeTo fields are required.
200 OK - The absence record was successfully updated. The response will contain a JSON object confirming the successful update.
400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
This endpoint allows you to delete an absence record specified by its unique id. Optionally, an eventDeleteMode can be provided to determine how the deletion should be handled. This is useful for removing individual absence entries that are no longer valid or were created by mistake.
/api/v1/Absences/{id}id provided is valid to avoid accidental deletions.0= Delete all events with the same request
1 = Delete only one event
200 OK - The absence definition was successfully deleted.
400 Bad Request - The request is invalid, possibly due to an incorrect id or invalid eventDeleteMode.
The Absences endpoint in the All Hours API allows users to efficiently manage employee absences. This endpoint supports retrieving, creating, updating, and deleting absence records. Key features include accessing a comprehensive list of absences, filtering records by parameters such as employee ID, date range, or absence type, and submitting new absence entries for approval or review.
\nThis parameter tells you on which days will a certain record be inserted on usually matters when you are doing bulk updates:
\n0 = On days where there is shift plan
1 = On all days
2 = Only workdays (usually from monday to friday)
0 = Automatically approved absence (without any notification about being it approved)
1 = Pending absence (awaiting approval or rejection).
2 = Approved absence
3 = Rejected absence
4 = Automatically approved absence (a notification for absence being approved is sent)
The timestamp format \"2024-10-25T15:05:07.987Z\" represents October 25, 2024, at 15:05 (3:05 PM), including 7.987 seconds. The \"Z\" at the end indicates UTC (Coordinated Universal Time), a global standard time zone to avoid discrepancies with local times.
The Origin parameter indicates the source of the request. Here are some of the possible values:
\n0 = TimeClock
2 = WebApplication
3 = AutoGenerated
4 = WebClock
5 = ApprovalWorkflow
7 = Time API
searchTermhttps://api4.allhours.com/api/v1/Absences?searchTerm=Makswell\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available absences.This endpoint retrieves a list of approval requests based on various filtering options, such as date range, user ID, event definitions, and request status.
\n/api/v1/ApprovalRequests200 OK - The approval requests were successfully retrieved. The response is in JSON format.
404 Not Found - The requested resource could not be found.
This endpoint allows you to delete an approval request specified by its unique ID. Use this endpoint to remove an approval request that is no longer required or was created in error.
\n/api/v1/ApprovalRequests/{id}id provided is valid to avoid errors.200 OK - The approval request was successfully deleted.
400 Bad Request - The request is invalid, possibly due to an incorrect ID or missing required parameters.
The /api/v1/ApprovalRequests endpoint allows users to manage approval requests within the system. It provides functionality to retrieve and delete approval requests. Users can fetch individual approval requests based on date and other query parameters.
This parameter tells you on which days will a certain record be inserted on usually matters when you are doing bulk updates:
\n0 = On days where there is shift plan
1 = On all days
2 = Only workdays (usually from monday to friday)
0 = All events
1 = Clockings
2 = Absences
3 = Interventions
5 = Corrections
1 = Pending approval request (awaiting approval or rejection).
2 = Approved approval request
3 = Rejected approval request
This endpoint retrieves a list of adjustment definitions. You can use the optional searchTerm query parameter to filter results based on a specific keyword. This is useful for narrowing down adjustments and improving search efficiency.
/api/v1/AdjustmentDefinitions200 OK - The request was successful, and a JSON response containing adjustment data was returned.
400 Bad Request - The request was malformed. This could happen if the searchTerm parameter contains invalid characters or is improperly formatted.
This endpoint retrieves detailed information about a specific adjustment definition by its unique identifier (id). This is useful for accessing information about a particular adjustment, such as \"Vacation entry\" or \"Balance correction.\"
id is in a valid UUID format to avoid errors.200 OK - The adjustment definition was successfully retrieved, and a JSON object containing the details is returned.
404 Not Found - No adjustment definition found for the specified id. This may occur if the id is invalid or does not exist.
The Adjustment Definitions endpoint lets you manage adjustments effectively using standard HTTP methods. You can retrieve, update, delete, list, and create adjustment definitions. Access details of a specific adjustment by ID, update its information, remove it, list all adjustments, or create new ones.
\n1 = System Adjustment (Means that Type of the adjustment can't be changed)
2 = Correction of Calculation Result
3 = Overwrite the Calculation Result
0 = No restriction (everybody can use this adjustment definition)
1 = Admin restriction (only admins have privilege of accessing this adjustment definition)
2 = Tag restriction (only people with a certain tag can use this adjustment definition)
searchTermhttps://api4.allhours.com/api/v1/AdjustmentDefinitions?searchTerm=Overtime entry\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available adjustment definitions.This endpoint retrieves a list of adjustments, with options to filter results by date range or a search term. By setting a start and/or end date, you can narrow down the adjustments to a specific period. Additionally, a search term can be used to refine the results based on specific adjustment details.
\n/api/v1/Adjustments200 OK - The adjustments were successfully retrieved, and a JSON response containing the adjustment data is returned.
400 Bad Request - The request was malformed. This may happen if the date format is incorrect or there is an issue with the query parameters.
This endpoint retrieves detailed information about a specific adjustment by its unique identifier (id). Use this endpoint to access information about a particular adjustment, such as its name, type, or other associated details.
/api/v1/Adjustments/{id}id provided is valid to avoid errors.200 OK - The adjustment was successfully retrieved, and a JSON object containing the adjustment details is returned.
404 Not Found - No adjustment was found for the specified id. This may occur if the id is invalid or does not exist.
This endpoint allows you to create a new adjustment record for a user. You must provide a JSON payload with all necessary details, including the user ID, adjustment definition ID, and other properties related to the adjustment.
\n/api/v1/AdjustmentsUserId (string, required): The unique id of the user for whom the adjustment record is created.
AdjustmentDefinitionId (string, required) :The unique id of the adjustment definition.
Value (number, required) : The value of the adjustment.
Timestamp (datetime, required): The date and time of when the adjustment will be created.
Status (integer, required): The status of the adjustment.
Origin (integer, optional): Indicates the source of the request
201 Created - The adjustment was successfully created, and the response includes the details of the new adjustment.
400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
This endpoint allows you to create multiple adjustment records in a single request. You must provide a JSON payload containing the necessary details for each adjustment, such as user IDs, adjustment definitions, and related parameters.
\n/api/v1/Adjustments/BulkUserId (string, required): The unique id of the user for whom the adjustment record is created.
AdjustmentDefinitionId (string, required): The unique id of the adjustment definition.
Value (number, required) : The value of the adjustment.
Timestamp (datetime, required): The date and time of when the adjustment will be created.
Status (integer, required): The status of the adjustment.
Origin (integer, optional): Indicates the source of the request
PeriodOptions (integer, required): Specifies the options for the adjustment period.
If IsPartial is true, then PartialTimeFrom and PartialTimeTo fields are required.
201 Created - The bulk adjustments were successfully created, and the response includes the details of the created adjustments.
400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
This endpoint allows you to update an adjustment record in the system. This is particularly useful for making corrections or updating details related to a specific adjustment. Each adjustment is identified by a unique identifier (id), which is provided as a path parameter. This endpoint expects a JSON object in the request body containing all the fields to be updated.
Endpoint: /api/v1/Adjustments/{id}
id (string, required): The id of the adjustment record.
UserId (string, required): The id of the associated user.
FirstName (string, required): User's first name.
LastName (string, required): User's last name.
Value (number, required): The numeric value of the adjustment.
Timestamp (string, required): The timestamp of when the adjustment was made.
AdjustmentDefinitionId (string, required): The id of the adjustment definition.
Status (string, optional): The status of the adjustment.
Origin (string, optional): The source of the adjustment record.
If IsPartial is true, then PartialTimeFrom and PartialTimeTo fields are required.
200 OK - The adjustment was successfully updated, and the response includes the details of the updated adjustment.
400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
This endpoint allows you to delete an existing adjustment record by providing its unique identifier (id). An optional eventDeleteMode query parameter can be specified to control deletion behavior.
/api/v1/Adjustments/{id}id provided is valid to avoid accidental deletions.0= Delete all events with the same request
1 = Delete only one event
200 OK - The adjustment was successfully deleted.
400 Bad Request - The request is invalid, possibly due to an incorrect or missing id.
The \"Adjustments\" endpoint is a handy tool for managing adjustment data. It lets you view, create, update, delete, and even handle multiple adjustments at once. Whether you need to make a quick change or manage a large set of adjustments, this endpoint makes it easy and efficient to get the job done.
\nThis parameter tells you on which days will a certain record be inserted on usually matters when you are doing bulk updates:
\n0 = On days where there is shift plan
1 = On all days
2 = Only workdays (usually from monday to friday)
0 = Automatically approved adjustment (without any notification about being it approved)
1 = Pending adjustment (awaiting approval or rejection).
2 = Approved adjustment
3 = Rejected adjustment
4 = Automatically approved adjustment (a notification for adjustment being approved is sent)
The timestamp format \"2024-10-25T15:05:07.987Z\" represents October 25, 2024, at 15:05 (3:05 PM), including 7.987 seconds. The \"Z\" at the end indicates UTC (Coordinated Universal Time), a global standard time zone to avoid discrepancies with local times.
The Origin parameter indicates the source of the request. Here are some of the possible values:
\n0 = TimeClock
2 = WebApplication
3 = AutoGenerated
4 = WebClock
5 = ApprovalWorkflow
7 = Time API
searchTermhttps://api4.allhours.com/api/v1/Adjustments?searchTerm=Makswell\n\nsearchTerm is optional and allows users to filter the adjustments (usually by name). When not provided, the endpoint returns all available adjustments.Retrieve a list of clocking definitions. Optionally filter results by a search term.
\n/api/v1/ClockingDefinitionssearchTerm is omitted, all available clocking definitions are returned.200 OK - The clocking definitions were successfully retrieved, and a JSON array containing the results is returned.
400 Bad Request - The request is invalid or malformed.
This endpoint retrieves a specific Clocking Definition by its unique identifier.
\n/api/v1/ClockingDefinitions/{id}200 OK - The clocking definition was successfully retrieved. The response includes the definition in JSON format.
404 Not Found - No clocking definition exists for the provided id.
Clocking Definitions in All Hours represent the events users register in the system, such as arrivals, departures, or absences. They allow organizations to define custom rules for how time entries are categorized and handled.
\nFor example:
\nA custom arrival might represent the start of a shift at a specific location.
\nA custom departure could represent leaving for a lunch break.
\nOther definitions can capture absence events or automatic system-generated events.
\nEach Clocking Definition has a unique identifier (id), a Type, and may include restrictions that determine who can use it.
The Type field specifies the kind of event the definition represents:
0 → Arrival User registers starting work.
1 → Departure User registers finishing work.
2 → AbsenceStart User registers the beginning of an absence.
3 → ReturningFromAbsence User registers the end of an absence.
4 → AutomaticEvent A system-generated event.
The RestrictionType field defines who can use the clocking definition:
0 → No restriction Any user can use this definition.
1 → Admin Restricted to administrators only.
2 → Tag restriction Restricted to users with a specific tag.
searchTermhttps://api4.allhours.com/api/v1/ClockingDefinitions?searchTerm=Ascension\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available adjustment definitions.This endpoint retrieves clocking records. Clockings represent the individual events registered by users, such as arrivals, departures, or absences. You can filter results by date range and search term.
\n/api/v1/Clockings200 OK - Clocking records were successfully retrieved. The response includes a JSON array of clockings.
400 Bad Request - The request was invalid, typically due to incorrectly formatted parameters.
This endpoint retrieves the geolocation data associated with a specific clocking. Geolocation details include information such as the coordinates and context of where the clocking event was recorded.
\n/api/v1/Clockings/{id}/GeoLocation200 OK - The geolocation data for the specified clocking was successfully retrieved. The response includes location details in JSON format.
400 Bad Request - The request was invalid, typically due to an incorrect or missing id.
This endpoint creates a new clocking. Clockings represent user-registered events such as arrivals, departures, or absences. Each clocking can include details like timestamps, clocking points and comments.
\n/api/v1/ClockingsComment (string, optional): A comment or note for the clocking event.
Origin (integer, optional): Identifies the source of the clocking (e.g., device, web, mobile).
Timestamp (string, required): The exact time when the clocking event occurred.
UserId (string, required): The unique identifier of the user performing the clocking.
ClockingPointId (string, optional): The unique identifier of the clocking point where the event occurred.
ClockingDefinitionId (string, required): The unique identifier of the clocking definition applied to this event (Arrival, Departure...).
201 Created - The clocking was successfully created. The response includes details of the new clocking.
400 Bad Request - The request was invalid, typically due to missing required fields or incorrectly formatted data.
This endpoint allows you to create multiple clockings in bulk. It is useful for registering time events across a specific period for a user, such as recording multiple workdays or recurring events.
\n/api/v1/Clockings/BulkComment (string, optional): A comment or note applied to the bulk clockings.
Origin (integer, optional): Identifies the source of the clockings (e.g., device, web, mobile).
UserId (string, required): The unique identifier of the user for whom the clockings are created.
ClockingDefinitionId (string, required): The unique identifier of the clocking definition to apply.
PeriodOptions (integer, optional): Defines on which days the clockings are inserted.
PeriodFrom (string, required): Start date and time of the bulk period.
PeriodTo (string, required): End date and time of the bulk period.
201 Created - The bulk clockings were successfully created. The response includes details of the created records.
400 Bad Request - The request was invalid, typically due to missing required fields or incorrectly formatted data.
This endpoint updates an existing clocking by its unique identifier (id). Use this to modify details of a clocking such as timestamp, comments, geolocation, or related definitions.
/api/v1/Clockings/{id}id in the URL matches the Id in the request body.Id (string, required): The unique identifier of the clocking. Must match the id path parameter.
Timestamp (string, required): The timestamp of the clocking.
OriginalTimestamp (string, optional): The original timestamp of the clocking.
IsAuthentic (boolean, optional): Whether the clocking is authentic.
Comment (string, optional): Comment associated with the clocking.
Origin (integer, optional): The origin code.
Status (string, optional): Status code if the clockinh went through approval workflow.
InsertedOn (string, optional): The datetime when the record was created.
IsModified (boolean, optional): Whether the clocking has been modified.
ModifiedByUser (string, optional): Identifier of the user who modified the record.
ModifiedOn (string, optional): The datetime when the record was last modified.
GeoLocationTimestamp (string, optional): Timestamp when geolocation was captured.
HasGeoLocation (boolean, optional): Indicates if the clocking has geolocation data.
Accuracy (integer, optional): Accuracy of the geolocation in meters.
UserId (string, required): Identifier of the user associated with the clocking.
FirstName (string, optional): The user’s first name.
MiddleName (string, optional): The user’s middle name.
LastName (string, optional): The user’s last name.
DeviceId (string, optional): Identifier of the device used for the clocking.
BeaconId (string, optional): Identifier of the beacon associated with the clocking.
ClockingPointId (string, optional): Identifier of the clocking point.
ClockingPointName (string, optional): Name of the clocking point.
ClockingDefinitionId (string, optional): Identifier of the clocking definition.
ClockingDefinitionName (string, optional): Name of the clocking definition.
200 OK - The clocking was successfully updated. The response includes the updated details.
400 Bad Request - The request was invalid, typically due to missing fields, invalid UUID, or mismatch between the path id and body Id.
This endpoint deletes an existing clocking by its unique identifier (id). Use this when you need to permanently remove a clocking record.
/api/v1/Clockings/{id}200 OK - The clocking was successfully deleted.
400 Bad Request - The request was invalid, typically due to a missing or invalid id.
Use the Clockings endpoints to create, read, update, and delete individual clocking records (timestamps) for users. A clocking includes time fields, user and point/definition references, optional device/beacon info, and optional geolocation.
\n0 = Automatically approved clocking (no notification is sent)
1 = Pending clocking (awaiting approval or rejection)
2 = Approved clocking
3 = Rejected clocking
4 = Automatically approved clocking (a notification is sent)
IsAuthenticfieldThe IsAuthentic field is true if the clocking was entered via the web app, mobile app, or a terminal using the standard “clock” button (which records the exact press time).
If a clocking is created through the “Add Clocking” option, it will not be authentic.
\nIf a clocking is modified after creation, it is also no longer considered authentic.
\nThe Origin parameter indicates the source of the clocking. Possible values include:
0 = TimeClock
2 = WebApplication
3 = AutoGenerated
4 = WebClock
5 = ApprovalWorkflow
7 = Time API
searchTermhttps://api4.allhours.com/api/v1/Clockings?searchTerm=Makswell\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available absences.Retrieve a list of calendar groups. Optionally filter results by a search term.
\n/api/v1/CalendarGroupssearchTerm is omitted, all available calendar groups are returned.HTTP Status
\n200 OK - The calendar groups were successfully retrieved, and a JSON array containing the results is returned.
404 Not Found - No calendar groups found for the given searchTerm or the resource does not exist.
Retrieve a single calendar group by its unique identifier.
\n/api/v1/CalendarGroupsid is in a valid UUID format to avoid errors.200 OK - The absence definition was successfully retrieved, and a JSON object containing the details is returned.
404 Not Found - No absence definition found for the specified id. This may occur if the id is invalid or does not exist.
Calendar Groups represent regional calendars in All Hours. Each group defines the time zone, country/region and standard workdays. They also serve as a containers for calendar events such as public (national) holidays and organization specific events.
\nThis section explains the TimeZone field.
TimeZone is a required string that must be a valid IANA time zone identifier (also called “tz database” names), e.g., Europe/London.
Use canonical IANA names like Europe/London, America/New_York, Asia/Dubai.
\nDo not send numeric offsets (+01:00) or Windows time zone IDs (GMT Standard Time).
\nThis section explains the Workdays field, which you’ll encounter when creating or updating calendar groups.
Workdays value is an integer bitmask (0–127) that encodes which days of the week are consideredBehavior Summary
\n62 → 2 + 4 + 8 + 16 + 32 → Monday–Friday.
127 → 1 + 2 + 4 + 8 + 16 + 32 + 64 → All days.
65 → 1 + 64 → Weekend only (Sunday + Saturday).
0 → No workdays.
searchTermPlain Text
\nhttps://api4.allhours.com/api/v1/CalendarGroups?searchTerm=Australia\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available adjustment definitions.This endpoint retrieves a list of calendar events. You can refine the results by using optional query parameters such as a specific keyword (searchTerm) or year (year).
/api/v1/CalendarEvents/Query200 OK - The calendar events were retrieved successfully. The response will contain a JSON array of calendar event objects.
400 Bad Request - The request is invalid, usually due to improperly formatted or incorrect query parameters.
This endpoint retrieves a list of all available calendar event types. The response does not require any parameters. New Calendar Event Types can be made but you have to contact support
\n/api/v1/CalendarEvents/Types\n\nNote: This endpoint doesn't support any querying and does not have any path parameters.
\n
200 OK - The calendar event types were retrieved successfully. The response will contain a JSON array of event type objects.
400 Bad Request - The request is invalid, typically due to malformed requests or headers.
This endpoint retrieves a list of available countries that can be used for importing calendar events (POST/api/v1/CalendarEvents/Import). No parameters are required for this endpoint. Upon successful request, the endpoint returns a JSON response containing country information.
/api/v1/CalendarEvents/Import/Countries\n\nNote: This endpoint doesn't support any querying and does not have any path parameters.
\n
200 OK - Successfully retrieved the list of countries. The response includes a JSON object containing the countries available for importing calendar events.
400 Bad Request - The request was malformed or invalid. This typically indicates issues with the request structure or headers.
The Calendar Events API provides functionality for managing calendar events, including creating, retrieving, updating, and deleting specific events. It allows users to fetch a list of all events, query events based on specific criteria, and retrieve available event types. Additionally, the API supports importing events from external sources and provides a list of countries available for event imports.
\n1 = Payday
2 = Holiday
3 = Vacation transfer
4 = Last year vacation limit
0 = Not recurring
1 = Weekly recurrence
2 = Bi-weekly recurrence
3 = Every month recurrence
4 = Every end of the month
5 = Yearly recurrence
searchTermhttps://api4.allhours.com/api/v1/CalendarEvents/?searchTerm=All Hours day\n\nsearchTerm is optional and allows users to filter the adjustments (usually by name). When not provided, the endpoint returns all available adjustments.This endpoint retrieves identifiers (e.g., badges) with optional filters for badge value or user details.
\n/api/v1/Identifiers200 OK - Matching identifiers were retrieved.
400 Bad Request - Invalid request (e.g., malformed query values).
This endpoint creates a new identifier. Identifiers are typically used to link badges or other unique values to users.
\n/api/v1/IdentifiersValue (string, required): The identifier value to create (e.g., badge number).201 Created - The identifier was successfully created. The response includes the created identifier.
400 Bad Request - The request was invalid, typically due to missing or incorrect fields.
This endpoint updates an existing identifier by its unique identifier (id). Use this to modify the value of an identifier such as a badge number.
/api/v1/Identifiers/{id}Id (string, required): The unique identifier of the identifier. Must match the id path parameter.
Value (string, required): The updated identifier value (e.g., badge number).
200 OK - The identifier was successfully updated. The response includes the updated record.
400 Bad Request - The request was invalid, typically due to missing fields or mismatch between the path id and body Id.
This endpoint deletes an existing identifier by its unique identifier (id). Ensure the id provided is valid to avoid accidental deletions.
/api/v1/Identifiers/{id}id is accurate to prevent unintended data loss.200 OK - The identifier was successfully deleted. The response includes confirmation details.
400 Bad Request - The request was invalid, typically due to an incorrect or missing id.
The Identifiers endpoints allow you to manage identifiers such as badge numbers and user-linked values. They provide functionality to create, retrieve, update, and delete identifiers, as well as list unassigned identifiers. These endpoints are typically used to connect physical or digital identifiers (like badges) with specific users, ensuring accurate tracking and access management.
\nbadgeSearchhttps://api4.allhours.com/api/v1/Identifiers?badgeSearch=056462123\n\nbadgeSearch is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available absences.This endpoint retrieves a list of organization units. You can use the optional filterType query parameter to filter results based on a specific type.
/api/v1/OrganizationUnits200 OK - The request was successful, and a JSON response containing organization units is returned.
400 Bad Request - The request was malformed. This could happen if the filterType parameter is invalid or improperly formatted.
This endpoint retrieves a list of subunits for a specific organization unit, identified by its unique id. You can optionally limit the response to only first-level subunits or include the parent unit in the results.
/api/v1/OrganizationUnits/{id}/Subunits200 OK - The request was successful, and a JSON response containing subunits (and optionally the parent unit) is returned.
404 Not Found - No organization unit was found for the specified id.
This endpoint allows you to create a new organization unit. Provide the unit details in the request body.
\n/api/v1/OrganizationUnitsName (string, required): The name of the organization unit.
ParentOrganizationUnitId (string, optional): UUID of the parent organization unit.
\n\nNote: Every All Hours account has a root organizational unit. When creating your first organizational units you should use the root organizational unit id as parent id
\n
201 Created - The organization unit was successfully created.
400 Bad Request - The request is invalid (e.g., missing required fields or invalid data types).
This endpoint updates an existing organization unit. Use it to change details such as the unit’s name, or parent relationship.
\n/api/v1/OrganizationUnitsId (string, required): The unique identifier of the organization unit to update.
Name (string, required): The name of the organization unit.
ParentOrganizationUnitId (string, optional): The unique identifier of the parent organization unit.
200 OK - The organization unit was successfully updated. The response includes the updated record.
400 Bad Request - The request was invalid, typically due to missing fields or invalid body parameters.
This endpoint deletes an existing organization unit by its unique identifier (id). Use this when you need to remove a department or organizational branch from the system.
/api/v1/OrganizationUnits/{id}id is accurate to prevent unintended data loss.200 OK - The organization unit was successfully deleted.
400 Bad Request - The request was invalid, typically due to an incorrect or missing id.
The OrganizationUnits endpoints allow you to manage the hierarchical structure of your organization. They provide functionality to create, retrieve, update, and delete organizational units, as well as list subunits and identify the root unit. These endpoints are commonly used to maintain department structures, define reporting relationships, and ensure an accurate representation of organizational hierarchies.
\nEvery All Hours account includes a predefined root organizational unit. When creating new units, they should be linked to this root unit as their parent to ensure proper placement within the hierarchy.
\n0 - User account restrictions should be applied.
1 - User account restrictions should not be applied.
This endpoint retrieves a list of tags defined in the system. Tags can be used to categorize or group users or other records for easier filtering and reporting. You can use the optional searchTerm query parameter to narrow results to tags containing a specific keyword.
/api/v1/Tags200 OK - The request was successful, and a JSON response containing tag data is returned.
400 Bad Request - The request was malformed, possibly due to invalid query parameters or formatting issues.
This endpoint allows you to create a new tag in the system. Tags can be used to categorize or group users or other records, enabling easier filtering and reporting.
\n/api/v1/TagsName (string, required): The name of the tag.
Color (integer, optional): Numeric value representing the tag’s color.
201 Created - The tag was successfully created, and the response includes the details of the newly created tag.
400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
Updates an existing tag by its unique identifier (id). This allows you to modify the tag’s name or color while keeping its unique identifier unchanged. The id in the path must match the Id provided in the request body.
/api/v1/Tags/{id}Id (string, required): Must match the id path parameter.
Name (string, required): The updated name of the tag.
Color (integer, optional): Numeric value representing the tag’s color.
200 OK - The tag was successfully updated.
400 Bad Request - The request was invalid, such as missing fields or mismatch between id and Id.
Deletes an existing tag by its unique identifier (id). Once deleted, the tag will no longer be available for grouping of records.
/api/v1/Tags/{id}200 OK - The tag was successfully deleted.
400 Bad Request - The request was invalid, typically due to a malformed or missing id.
The Tags endpoint manages tag records used to categorize and group users or other entities. It supports creating new tags, retrieving existing tags by ID or through search, updating tag details, and deleting tags. This allows administrators to maintain a structured tagging system for easier filtering, reporting, and organization across the platform. Responses are returned in JSON format.
\n","auth":{"type":"noauth","isInherited":false},"_postman_id":"b7942997-783a-4da0-ab29-284e81733910"},{"name":"Time Policies","item":[{"name":"Get Time Policies","id":"753aea77-5e80-4cb6-95b5-8c33deb2cae0","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"auth":{"type":"oauth2","oauth2":{"basicConfig":[]},"isInherited":false},"method":"GET","header":[{"key":"Accept","value":"application/json"},{"key":"Authorization","value":"{{AccessToken}}"}],"url":"https://api4.allhours.com/api/v1/TimePolicies","description":"Retrieves a list of time policies defined in the system. You can optionally filter results with a search term.
\n/api/v1/TimePolicies200 OK - A JSON array of time policies is returned.
400 Bad Request - The request was invalid, typically due to incorrect query parameters.
Time Policies define working rules in All Hours. They represent the building blocks of work plans and are used to control schedules, attendance, and reporting logic. Each time policy includes a name, optional description, and color for easier identification.
\n\n\nNote: Creating a time policy through this endpoint inherits system defaults. It’s recommended to manually review and adjust the settings afterward.
\n
searchTermhttps://api4.allhours.com/api/v1/TimePolicies?searchTerm=Overtime\n\nsearchTerm is optional and allows users to filter time policies (usually by name). When not provided, the endpoint returns all available time policies.Retrieves a list of work plans defined in the system. Work plans describe scheduled working arrangements that can be assigned to employees. You can optionally filter results by providing a search term.
\n/api/v1/WorkPlans200 OK - The request was successful, and a JSON array of work plans is returned.
400 Bad Request - The request was invalid, possibly due to incorrect query parameters or formatting issues.
Retrieves the details of a specific work plan by its unique identifier (id). This allows you to view the full configuration of a single work plan, including its assigned rules and scheduling information.
/api/v1/WorkPlans/{id}200 OK - The request was successful, and the response includes the details of the specified work plan.
404 Not Found - No work plan exists with the provided id.
Work Plans define scheduled working arrangements and the set of time policies that apply to them. You can create, retrieve, update, delete, and list work plans, and attach one or more Work Plan Policies that control which days/times a policy applies.
\nThis field controls how a work plan selects the active time policy.
\n0 = Automatic time policy selection
1 = Rotating time policy selection
This field appears on WorkPlanPolicies and limits when a policy applies.
\nIt’s an integer bitmask (0–127) for days of the week:
\nSunday = 1
Monday = 2
Tuesday = 4
Wednesday = 8
Thursday = 16
Friday = 32
Saturday = 64
Behavior Summary
\n62 → 2+4+8+16+32 → Monday–Friday
127 → 1+2+4+8+16+32+64 → All days
65 → 1+64 → Weekend only (Sunday + Saturday)
0 → No days (restriction on days never applies)
These fields limit the allowed arrival time for a policy. Values are in minutes since 00:00.
\nArrivalRestrictionFromValue – start of the window
ArrivalRestrictionToValue – end of the window
Examples
\n360 → 06:00 (because 360 min = 6 hours)
420 → 07:00
From=360 and To=420 → arrival must be between 06:00 and 07:00
searchTermhttps://api4.allhours.com/api/v1/WorkPlans?searchTerm=Night\n\nsearchTerm is optional and filters work plans (usually by name). When not provided, the endpoint returns all available work plans.This endpoint retrieves available clocking points. Clocking points represent physical or virtual locations where users can register arrivals, departures, or other clocking events.
\n/api/v1/ClockingPointssearchTerm is provided, all available clocking points are returned.200 OK - Clocking point data was successfully retrieved. The response includes a JSON array of clocking points.
400 Bad Request - The request was invalid, typically due to an incorrectly formatted searchTerm.
This endpoint retrieves all available clocking points along with their related details. The response not only includes the clocking point definitions but also the associated data such as geolocations, beacons, time terminals and other linked configurations.
\n/api/v1/ClockingPoints/Summary\n\nNote: This endpoint doesn't support any querying and does not have any path parameters.
\n
200 OK - Clocking points and their related details were successfully retrieved. The response includes a JSON array with clocking points, geolocation data, beacons, and other nested objects.
400 Bad Request - The request was invalid.
This endpoint allows you to create a new clocking point. Clocking points represent physical or virtual locations where users can register their arrivals, departures, or other clocking events.
\n/api/v1/ClockingPointsName (string, required): The display name of the clocking point.
Description (string, optional): A descriptive text about the clocking point.
201 Created - The clocking point was successfully created. The response includes the details of the newly created clocking point.
400 Bad Request - The request was invalid, typically due to missing required fields or incorrectly formatted data.
This endpoint updates an existing clocking point by its unique identifier (id). Use this to modify the clocking point’s name or description.
/api/v1/ClockingPoints/{id}id in the URL matches the Id in the request body.Id (string, required): The unique identifier of the clocking point. Must match the id path parameter.
Name (string, optional): The name of the clocking point.
Description (string, optional): A descriptive text about the clocking point.
200 OK - The clocking point was successfully updated. The response includes the updated details.
400 Bad Request - The request was invalid, typically due to missing fields, an invalid UUID, or mismatch between the path id and body Id.
This endpoint deletes an existing clocking point by its unique identifier (id). Ensure the id provided is valid to avoid accidental deletions. Deleting a clocking point will also remove its associated data such as geolocation and beacons.
/api/v1/ClockingPoints/{id}id is accurate to prevent unintended data loss.200 OK - The clocking point was successfully deleted. The response includes confirmation details.
400 Bad Request - The request was invalid, typically due to an incorrect or missing id.
Clocking Points represent the physical or virtual locations where users register their clocking events, such as arrivals, departures, or absences. Each clocking point can include additional details like descriptions, geolocation, and connected beacons.
\nThe ClockingPoints API provides endpoints to create, retrieve, update, delete, and summarize clocking points, ensuring full control over how and where time events are recorded.
\nsearchTermhttps://api4.allhours.com/api/v1/ClockingPoints?searchTerm=ZT\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available adjustment definitions.This endpoint retrieves geolocation data linked to clocking points. You can filter the results either by providing a clockingPointId or by using a searchTerm keyword.
/api/v1/GeoLocations200 OK - Geolocation data was successfully retrieved. The response contains a list of geolocation records in JSON format.
400 Bad Request - The request was invalid, typically due to incorrect parameter values.
Creates a new geolocation record associated with a clocking point.
\n/api/v1/GeoLocationsName (string, required): The name of the geolocation.
Latitude (number, required): The latitude coordinate of the geolocation.
Longitude (number, required): The longitude coordinate of the geolocation.
Radius (number, required): The radius around the geolocation point in meters.
ClockingPointId (string, required): The unique identifier of the clocking point the geolocation belongs to.
201 Created - The geolocation was successfully created. The response includes the created geolocation record.
400 Bad Request - The request was invalid, typically due to missing or incorrect fields.
Updates an existing geolocation record by its unique identifier (id).
/api/v1/GeoLocations/{id}Id (string, required): The unique identifier of the geolocation. Must match the id path parameter.
Name (string, required): The name of the geolocation.
Latitude (number, required): The latitude coordinate of the geolocation.
Longitude (number, required): The longitude coordinate of the geolocation.
Radius (number, required): The radius around the geolocation point in meters.
200 OK - The geolocation was successfully updated. The response includes the updated geolocation record.
400 Bad Request - The request was invalid, typically due to missing or incorrect fields, or a mismatch between the path id and body Id.
This endpoint deletes an existing geolocation by its unique identifier (id). Ensure the id provided is valid to avoid accidental deletions.
/api/v1/GeoLocations/{id}id is accurate to prevent unintended data loss.200 OK - The geolocation was successfully deleted. The response includes confirmation details.
400 Bad Request - The request was invalid, typically due to an incorrect or missing id.
The GeoLocations endpoints allow you to manage geolocations linked to clocking points. They let you create, retrieve, update, and delete geolocation records. Each geolocation includes a name, coordinates (latitude and longitude), and a radius, and is associated with a specific clocking point. These endpoints are typically used to define physical boundaries for clockings, such as office locations or work zones.
\nsearchTermhttps://api4.allhours.com/api/v1/GeoLocations?searchTerm=The Sea\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available absences.This endpoint retrieves a list of beacons, which can be filtered using a clocking point ID or a search term.
\n/api/v1/Beacons200 OK - The request was successful, and the response contains beacon data in JSON format.400 Bad Request - The request was malformed, possibly due to invalid query parameters.
This endpoint allows you to create a new beacon entry. The request must include a JSON payload with the necessary details, such as the beacon's name, major and minor values, associated clocking point ID, and UUID.
\n/api/v1/BeaconsName (string, required): The name of the beacon.
MajorValue (integer, required): The major value assigned to the beacon.
MinorValue (integer, required): The minor value assigned to the beacon.
ClockingPointId (string, required): The unique identifier of the clocking point associated with the beacon.
Uuid (string, required): The universally unique identifier (UUID) of the beacon.
MajorValue and MinorValue must be valid integers.
ClockingPointId and Uuid should be valid UUIDs.
201 Created - The beacon was successfully created, and the response includes the details of the new beacon.400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
This API endpoint allows you to update an existing beacon by specifying its unique identifier (id) in the path and providing the updated details in the request body also it ensures that beacon information remains up to date while maintaining data integrity.
/api/v1/Beacons/{id}id in the path must match the Id field in the request body.Id (string, required): The unique identifier of the beacon.
Name (string, required): The updated name of the beacon.
MajorValue (integer, required): The major value assigned to the beacon.
MinorValue (integer, required): The minor value assigned to the beacon.
200 OK - The beacon was successfully updated. The response contains a JSON object confirming the successful update.400 Bad Request - The request is invalid, possibly due to missing required fields or incorrect data formats.
This API endpoint allows you to delete an existing beacon by specifying its unique identifier (id) in the path.
/api/v1/Beacons/{id}id exists before making the delete request.200 OK - The beacon was successfully deleted.400 Bad Request - The request is invalid, possibly due to an incorrect or missing id.
The Beacons API allows users to manage beacon information efficiently. It lets you add new beacons, view specific or all existing ones, update details when needed, or remove outdated entries all in a straightforward way.
\nsearchTermhttps://api4.allhours.com/api/v1/Beacons?searchTerm=Beacon1\n\nsearchTerm is optional and allows users to filter the adjustments (usually by name). When not provided, the endpoint returns all available adjustments.This endpoint retrieves user records with options to filter results by search term, tag IDs, or organizational unit IDs. You can use these filters to narrow down the user list to specific categories or organizational segments.
\nThis is ideal for user management features such as listing, searching, filtering by tags or units, or building administrative tools for managing users across departments.
\n/api/v1/Users200 OK – The request was successful, and a JSON response containing user data is returned.
400 Bad Request – The request was malformed. This may happen if the query parameters are invalid or improperly formatted.
This endpoint retrieves a list of users with basic profile information. It supports optional filtering based on search terms, tags, organization units, and user types. This is useful when a lightweight version of user data is required, such as for user selection dialogs or system integrations.
\n/api/v1/Users/Basic200 OK - The request was successful, and a JSON response containing the filtered list of users is returned.This endpoint retrieves a detailed summary of users, providing more than just basic user information. It allows filtering by search term. This is ideal when you need a comprehensive view of users including their associated work plans, organizational units, calendar groups, authorization roles, identifiers, tags, and more.
\n/api/v1/Users/Summary/Query200 OK – The request was successful and a JSON array of user summaries is returned.This endpoint allows you to create a new user within the system by submitting the necessary user information in the request body. It is commonly used to onboard new employees or system users by providing personal details, contact information, and custom fields.
\n/api/v1/UsersFirstName (string, required): The user's first name.
LastName (string, required): The user's last name.
Email (string, optional): User's email
CalculationStartDate (date, required): The date when the user becomes active in the program.
CalculationStopDate (date, optional): In case you are using POST you should leave this empty
IsTimeAttendanceUser (boolean, optional): Field which toggles if the user is visible on Time&Attendece views
IsArchived (boolean, optional): Changes the archive status for the user
SendInvite (boolean, optional): Sends the user an email invitation containing a URL to set their access code
HasUserAccount (boolean, required): Set to True if the user has an email address; otherwise, set to False.
UserAccountId (boolean, required): This field should always be null as it will be auto-populated with a UUID in case the user has an email address present
201 Created - The user was successfully created, and a JSON object containing the new user's details is returned.
400 Bad Request - The request was malformed. This can occur if any required fields are missing or incorrectly formatted.
This endpoint allows you to archive multiple users in bulk by submitting a list of user records in the request body. Archiving users is helpful when users leave the organization or need to be deactivated from the time and attendance system without permanently deleting their records.
\n/api/v1/Users/Archive/BulkUserId (string, required): The unique identifier of the user to be archived.
IsTimeAttendanceUser (boolean, required): Indicates whether the user will still be visible on time and attendance views.
ArchiveAt (string, required): The date and time at which the user should be archived.
200 OK - The users were successfully archived, and a confirmation is returned.
400 Bad Request - The request was malformed. This could be due to missing required fields or incorrectly formatted data.
This endpoint allows for importing one or more users into the system with detailed account, attendance, and organizational information. It is typically used during initial data setup or for syncing users from an external system.
\n/api/v1/Users/ImportFirstName (string, required): The user's first name.
LastName (string, required): The user's last name.
Email (string, optional): User's email
CalculationStartDate (date, required): The date when the user becomes active in the program.
IsTimeAttendanceUser (boolean, optional): Field which toggles if the user is visible on Time&Attendece views
IsArchived (boolean, optional): Changes the archive status for the user
SendInvite (boolean, optional): Sends the user an email invitation containing a URL to set their access code
HasUserAccount (boolean, required): Set to True if the user has an email address; otherwise, set to False.
UserAccountId (boolean, required): This field should always be null as it will be auto-populated with a UUID in case the user has an email address present
IdentifierIds (array of strings, optional): List of identifier IDs associated with the user.
AuthorizationRoleIds (array of strings, optional): IDs of the roles assigned to the user.
BalanceOfHours (integer, optional): Total balanced hours assigned to the user.
VacationDays (integer, optional): All vacation days last years + this years.
LastYearVacationDays (integer, optional): Remaining vacation days from the previous year.
OrganizationUnits (string, optional): The name of the user's organizational unit. In case the users organizational unit is subdepartment the field should be UNIT/SUBUNIT/SUBUNIT1.
WorkPlanId (string, optional): The ID of the workplan assigned to the user.
TraceId (string, required): A unique identifier used for tracking or logging the request.
201 Created - The users were successfully imported, and a JSON response confirming creation is returned.
400 Bad Request - The request was invalid, typically due to missing required fields or improperly formatted input.
This endpoint is used to set or completely replace user balances in bulk whether you're adding new users or need to wipe and reload existing balances. It's typically applied when updating vacation days, carryover time, or hour balances across multiple users.
\n/api/v1/Users/Import/BalanceEmail (string, required): The user's email address used for identification.
FirstName (string, required): The user's first name.
LastName (string, required): The user's last name.
TraceId (string, optional): A unique identifier used for tracking or logging the request.
BalanceOfHours (integer, optional): Total balanced hours assigned to the user.
VacationDays (integer, optional): All vacation days (last years + this years).
LastYearVacationDays (integer, optional): Remaining vacation days from the previous year.
BalancesUpdateDate (date, required): The date on which the balance data will be updated
201 Created - The user balances were successfully imported, and a confirmation response is returned.
400 Bad Request - The request was invalid, often due to missing required fields or formatting issues.
This endpoint is used to set or update vacation quota values for users in bulk. It supports overwriting existing balances or inserting new vacation data. This is useful for initializing or adjusting users' time-off entitlements for a given period.
\n/api/v1/Users/Import/VacationEmail (string, required): The user's email address used for identification.
FirstName (string, required): The user's first name.
LastName (string, required): The user's last name.
TraceId (string, optional): A unique identifier used for tracking or logging the request.
VacationQuota (integer, required): The number of vacation days being allocated to the user
Timestamp (date, required): The date and time when the quota is applied, in ISO 8601 format.
OverrideExistingVacationBalances (boolean, required): If set to true, the existing vacation balance will be replaced with the new value provided.
\n\nNote: As demonstrated in the request, if the user does not have an email address, the import can still be processed using just the first name and last name for identification.
\n
200 OK - The vacation quotas were successfully processed, and a JSON response confirms the outcome.
400 Bad Request - The request was invalid, likely due to missing required fields or incorrect formatting.
This endpoint allows you to update multiple users in bulk by submitting a list of user objects with updated profile information. This is useful for large-scale user data maintenance, such as updating contact details, custom fields, or status attributes across many users.
\n/api/v1/Users/BulkId (string, required): The unique identifier of the user being updated.
FirstName (string, required): The user's first name.
LastName (string, required): The user's last name.
Email (string, optional): User's email
CalculationStartDate (date, optional): The date when the user becomes active in the program.
CalculationStopDate (date, optional): In case you are using POST you should leave this empty
IsTimeAttendanceUser (boolean, optional): Field which toggles if the user is visible on Time&Attendece views
IsArchived (boolean, optional): Changes the archive status for the user
SendInvite (boolean, optional): Sends the user an email invitation containing a URL to set their access code
HasUserAccount (boolean, required): Set to True if the user has an email address; otherwise, set to False.
UserAccountId (boolean, required): This field should always be null as it will be auto-populated with a UUID in case the user has an email address present
\n\nNote: When using this PUT endpoint, include only the data you want to stay the same and the specific fields you wish to update in the request body. Any fields you omit will be reset to system defaults (typically null or empty values).
\n
\n\nExample: If you delete the field Email: \"Email_Example\" from the body and make a request, the user will lose the email they previously had it will be cleared.
\n
200 OK - The user data was successfully updated, and the response confirms the successful update.
400 Bad Request - The request was invalid, typically due to missing required fields or incorrect formatting.
This endpoint allows you to delete multiple users at once by providing a list of their unique user IDs. It is typically used for cleaning up test data or removing users who are no longer part of the system.
\n/api/v1/Users/BulkUserIds (string, required): A list of user IDs that should be deleted from the system.200 OK - The users were successfully deleted from the system.
400 Bad Request - The request was invalid, possibly due to missing or incorrectly formatted user IDs.
The Users endpoints allow you to manage user data within the All Hours system using standard HTTP methods. You can retrieve, create, import, update, and delete users in bulk or individually. These endpoints support a variety of use cases, such as onboarding new employees, updating user details, assigning roles, managing balances, and archiving accounts.
\nEach endpoint supports specific operations, from retrieving basic user information for listings, to fully updating or importing complex user records including balances and vacation quotas.
\nThis section explains the UserAccount field, which you will encounter in the endpoints below.
The UserAccountId is a unique identifier that is automatically generated when a user is assigned an email address. You can think of it as the system's internal ID that links directly to the user's email-based login.
If the user has an email:
\nSet UserAccountId to null it will be automatically generated.
Set HasUserAccount to true.
If the user does not have an email:
\nLeave UserAccountId as null.
Set HasUserAccount to false.
When using PUT endpoints (such as bulk updates), ALWAYS include the existing UserAccountId in your request payload. Failing to do so may break the link between the user and their login account, causing data inconsistency or disconnection between user records.
A client-defined identifier used to track individual records in bulk operations. This value is echoed back in the API response to help correlate each response item with its original input.
\nIt is not used for identifying or updating users in the system and has no functional impact on the operation itself.
\nTraceId like \"user001\", \"user002\", etc. The response will return these same IDs alongside success or error information, making it easier to troubleshoot specific entries.searchTermhttps://api4.allhours.com/api/v1/Users/Summary/Query?searchTerm=Makswell\n\nsearchTerm is optional and allows users to filter the absences (usually by name). When not provided, the endpoint returns all available adjustment definitions.This endpoint retrieves all payroll repository data. It does not accept any query parameters and returns payroll records in JSON format.
\n/api/v1/Payrolls/repository\n\nNote: This endpoint doesn't support any querying and does not have any path parameters.
\n
200 OK - The payroll repository data was successfully retrieved. The response includes payroll records in JSON format.This endpoint retrieves payroll user data for a specified date range. The data is displayed based on payroll settings. You can further filter results using organizational unit IDs or tag IDs.
\n/api/v1/PayRolls200 OK - The payroll data was successfully retrieved. The response includes payroll records in JSON format.
400 Bad Request - The request was invalid, typically due to incorrect or missing parameters.
This endpoint retrieves payroll data for a specific payroll report, identified by its unique reportId. A date range must be provided, and results can be further filtered by organizational unit IDs or tag IDs.
/api/v1/PayRolls/{reportId}200 OK - The payroll report data was successfully retrieved. The response includes payroll records in JSON format.
400 Bad Request - The request was invalid, typically due to missing or incorrect parameters.
The Payrolls endpoint retrieves payroll data within a specified date range. It requires dateFrom and dateTo values to define the period and supports optional filters like organizationUnitId and tagId to narrow down results. This allows you to generate payroll information for specific timeframes, departments, or tagged groups of employees. The response returns payroll records in JSON format.
This endpoint retrieves a list of audit logs based on various filtering criteria such as user ID, action type, date range, search term, and entity type.
\n/api/v1/AuditLogs200 OK - The request was successful, and the response contains the audit logs in JSON format.400 Bad Request - The request was malformed, possibly due to invalid query parameters.
This endpoint retrieves a list of available audit log types, which can be used to filter logs based on specific actions.
\n/api/v1/AuditLogs/Types\n\nNote: This endpoint doesn't support any querying and does not have any path parameters.
\n
200 OK - The request was successful, and the response contains a list of audit log types in JSON format.
The AuditLogs endpoint provide access to system audit logs, enabling tracking, monitoring, and analysis for purposes like compliance, troubleshooting, and security.
\nsearchTermhttps://api4.allhours.com/api/v1/AuditLogs?searchTerm=Jery\n\nsearchTerm is optional and allows users to filter the adjustments (usually by name). When not provided, the endpoint returns all available adjustments.