Scribd
Upload
409 views9 pages

Teamlogger API Documentation

This document provides API documentation for managing projects and tasks within the TeamLogger platform. It includes details on authentication, various API calls for listing users, projects, and tasks, as well as creating, modifying, and managing project and task assignments. Additionally, it outlines how to generate reports and manage employee time tracking.

Uploaded by

santhosh
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
409 views9 pages

Teamlogger API Documentation

This document provides API documentation for managing projects and tasks within the TeamLogger platform. It includes details on authentication, various API calls for listing users, projects, and tasks, as well as creating, modifying, and managing project and task assignments. Additionally, it outlines how to generate reports and manage employee time tracking.

Uploaded by

santhosh
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

API Documentation

Authentiaction
Please use the key above as a bearer token. Your autorization request header should
look like this.

Authorization: Bearer YOUR_API_KEY_VALUE_HERE

API Calls
List Users
[GET] [Link]
List Projects
[GET] [Link]
include_all (boolean): Set this true to get all projects instead of just active
projects

Most recent tasks


[GET] [Link]
Returns a list of most recent project and task that the employees have worked on in
the last one hour. It also returns a unix timestamp in milliseconds with each entry
for the most recent activity.

Get Project Details


[GET] [Link]
project_id=prjid
prjid (string): The id of the project for which you need the details.

active_only (true/false): Set to true to return only the active tasks in task list.

[GET] [Link]
tskid (string): The id of the task for which you need the details.

Employee Summary Report


[GET] [Link]
startTime=start_time_epoch_ms&endTime=end_time_epoch_ms
startTime (long integer): Start time of the summary report in milliseconds since
UNIX epoch.

endTime (long integer): End time of the summary report in milliseconds since UNIX
epoch.

Projectwise Employee Summary Report


[GET] [Link]
startTime=start_time_epoch_ms&endTime=end_time_epoch_ms&daywise=daywise_flag
startTime (long integer): Start time of the summary report in milliseconds since
UNIX epoch.

endTime (long integer): End time of the summary report in milliseconds since UNIX
epoch.

daywise (true or false): Set this to true if you want the data to be also grouped
daywise.

Project Summary Report


[GET] [Link]
startTime=start_time_epoch_ms&endTime=end_time_epoch_ms
startTime (long integer): Start time of the summary report in milliseconds since
UNIX epoch.

endTime (long integer): End time of the summary report in milliseconds since UNIX
epoch.

Task Summary Report


[GET] [Link]
startTime=start_time_epoch_ms&endTime=end_time_epoch_ms&projectId=project_id
startTime (long integer): Start time of the summary report in milliseconds since
UNIX epoch.

endTime (long integer): End time of the summary report in milliseconds since UNIX
epoch.

projectId (string): The unique id of the project as per the response of


list_projects API.

Raw timesheet data


[GET] [Link]
startTime=start_time_epoch_ms&endTime=end_time_epoch_ms
startTime (long integer): Start time of the summary report in milliseconds since
UNIX epoch.

endTime (long integer): End time of the summary report in milliseconds since UNIX
epoch.

accountId (string): The id of the user as per the 'List Users' API.

projectId (string): The id of the project as per the 'List Projects' API.

taskId (string): The id of the task as per the 'Get Project Details' API.

Company punch in out report


[GET] [Link]
year=2023&month=10&day=10&timezoneOffsetMinutes=330&dayStartsAtHours=6&dayEndsAtHou
rs=23
year (integer, required): The year of the day for which the punch-in/out report is
being requested.

month (integer, required): The month of the day for which the punch-in/out report
is being requested.

day (integer, required): The day of the day for which the punch-in/out report is
being requested.

timezoneOffsetMinutes (integer, required): The time zone offset in minutes from UTC
for example for India GMT +530 this will be 330.

dayStartsAtHours (double, optional): The start time for the day in hours before
which punch in is not allowed.

dayEndsAtHours (double, optional): The end time for the day in hours which is the
last allowed punch out time.

Application and website usage report


[GET] [Link]
employee=TJ001&year=2023&month=10&day=22&timezoneOffsetMinutes=330&dayStartsAtHours
=6&dayEndsAtHours=23
employee (string, required): The email id or the employee name for whom the report
is being requested.

year (integer, required): The year of the day for which the punch-in/out report is
being requested.

month (integer, required): The month of the day for which the punch-in/out report
is being requested.

day (integer, required): The day of the day for which the punch-in/out report is
being requested.

timezoneOffsetMinutes (integer, required): The time zone offset in minutes from UTC
for example for India GMT +530 this will be 330.

dayStartsAtHours (double, optional): The start time for the day in hours before
which punch in is not allowed.

dayEndsAtHours (double, optional): The end time for the day in hours which is the
last allowed punch out time.

Create a new project


[POST] [Link]
name (string): The name of the project.

type (string): The type of project. One of OPEN or RESTRICTED ( case-sensitive ).

external_id (string, optional): Id to track integration with other systems.

All employees of the company can work on OPEN projects.

Only project MEMBERs or MANAGERs can work on RESTRICTED projects.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Project", "type":"OPEN" }' \
[Link]

Add user to a project


[POST] [Link]
assignee_email (string): Email address of the user to be removed from the project.

project_name/project_id (string): The name of the project (case-sensitive) or


project id.

role (string): The role of the user. One of MANAGER or MEMBER (case-sensitive).

Example:
Note: You do not need to add/remove project to an OPEN project. All employees can
work on OPEN projects.
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "assignee_email":"emp@[Link]", "project_name":"My Project",
"role":"MEMBER" }' \
[Link]

Change project name


[POST] [Link]
new_project_name (string): The new desired project name.

project_id (string): The id of the project to be renamed.


Change project external id
[POST] [Link]
new_external_id (string): The new external id for integration. Cannot be blank or
empty.

project_id (string): The id of the task to be renamed.

Change task name


[POST] [Link]
new_task_name (string): The new desired task name.

task_id (string): The id of the task to be renamed.

Change task name


[POST] [Link]
new_external_id (string): The new external id for integration. Cannot be blank or
empty.

task_id (string): The id of the task to be renamed.

Remove user from a project


[POST] [Link]
assignee_email (string): Email address of the user to be removed from the project.

project_name/project_id (string): The name of the project (case-sensitive) or


project id.

role (string): The role from which to remove the user. One of MANAGER or MEMBER
( case-sensitive ).

Example:
Note: You do not need to add/remove project to an OPEN project. All employees can
work on OPEN projects.
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "assignee_email":"emp@[Link]", "project_name":"My Project",
"role":"MEMBER" }' \
[Link]

Mark project as completed


[POST] [Link]
project_id (string): The id of the project to mark complete.

name (string): The name of the project to mark complete. This is not required to be
provided if project_id is provided.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Project" }' \
[Link]

Cancel project
[POST] [Link]
project_id (string): The id of the project to cancel.

name (string): The name of the project to cancel. This is not required to be
provided if project_id is provided.
Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Project" }' \
[Link]

Create a new task


[POST] [Link]
name (string): The name of the task.

project_id (string): The id of the project under which the tast will be added.

project_name (string): The name of the project under which the tast will be added.
Do not provide this if project_id is provided.

assignee_email (string) OPTIONAL: If not specified all project members (in case of
a RESTRICTED project) or all employees (in case of an OPEN project) will be able to
work on this task.

nonbillable (boolean): Set this to true to make task non-billable, set this to
false to make task billable.

external_id (string, optional): Id to track integration with other systems.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project",
"assignee_email":"emp@[Link]", "nonbillable":false }' \
[Link]

Create a new task (multiple assignees)


[POST] [Link]
name (string): The name of the task.

project_name (string): The name of the project under which the tast will be added.

assignee_emails (array of strings) : The list of emails of employees to whom the


task is assigned.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project", "assignee_emails":
["emp1@[Link]","emp2@[Link]"] }' \
[Link]

Reassign a task
[POST] [Link]
task_id (string): The id of the task to be reassigned.

name (string): The name of the task to be reassigned. This is not required is
task_id is provided.

project_id (string): The id of the project under which the task is to be


reassigned.

project_name (string): The name of the project under which the task is to be
reassigned. This is not required if project_id is provided.
assignee_email (string) OPTIONAL: If not specified all project members (in case of
a RESTRICTED project) or all employees (in case of an OPEN project) will be able to
work on this task.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project",
"assignee_email":"emp@[Link]" }' \
[Link]

Reassign a task (multiple assignees)


[POST] [Link]
task_id (string): The id of the task to be reassigned.

name (string): The name of the task. This is not required to be provided if task_id
is provided.

project_id (string): The id of the project.

project_name (string): The name of the project under which the task is to be
reassigned. This is not required to be provided if project_id is provided.

assignee_emails (array of strings) : The list of emails of employees to whom the


task is assigned.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project", "assignee_emails":
["emp1@[Link]","emp2@[Link]"] }' \
[Link]

Mark task as completed


[POST] [Link]
project_id (string): The id of the project the task belongs to.

project_name (string): The name of the project the task belongs to. (Do not provide
this if project_id is provided)

task_id (string): The id of the task to mark complete.

name (string): The name of the task to mark complete. This is not required to be
provided if task_id is provided.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project" }' \
[Link]

Reactivate task
[POST] [Link]
project_id (string): The id of the project the task belongs to.

project_name (string): The name of the project the task belongs to. (Do not provide
this if project_id is provided)
task_id (string): The id of the task to reactivate (mark as pending).

name (string): The name of the task to reactivate (mark as pending). This is not
required to be provided if task_id is provided.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project" }' \
[Link]

Cancel Task
[POST] [Link]
project_id (string): The id of the project the task belongs to.

project_name (string): The name of the project the task belongs to. (Do not provide
this if project_id is provided)

task_id (string): The id of the task to cancel.

name (string): The name of the task to cancel. This is not required to be provided
if task_id is provided.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project" }' \
[Link]

S task as completed
[POST] [Link]
project_id (string): The id of the project the task belongs to.

project_name (string): The name of the project the task belongs to. Do not prvoide
this if project_id parameter is provided.

task_id (string): The id of the task to mark complete.

name (string): The name of the task to mark complete. This is not required to be
provided if task_id is provided.

nonbillable (boolean): Set this to true to make task non-billable, set this to
false to make task billable.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "name":"My Task", "project_name":"My Project", "nonbillable":true }' \
[Link]

Add a manual time entry


[POST] [Link]
employee_email (string): The email address of the employee as per user record on
[Link] ( case-sensitive ).

task_id (string): The task id for which to record the manual entry. If task_id is
provided, do no provide project_name or task_name.

project_name (string): The name of the project ( case-sensitive ).


task_name (string): The name of the task ( case-sensitive ).

start_time: Start time in unix milliseconds.

end_time: End time in unix milliseconds.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" --request POST \
--data '{ "start_time":1666152000000, "end_time":1666153000000,
"employee_email":"employee@[Link]", "project_name":"My Project",
"task_name":"My Task"}' \
[Link]

Get Manual Entries


[GET] [Link]
Retrieves a list of manual entries associated with the authenticated user.

Response Fields:
id (string): The unique identifier of the manual entry.

startTime (datetime): The start time of the manual entry.

endTime (datetime): The end time of the manual entry.

status (string): The status of the work session (e.g., Approved, Rejected).

employeeName (string): The name of the employee associated with the entry.

employeeCode (string): The unique code of the employee.

employeeEmail (string): The email of the employee.

Example:
curl --header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" \
--request GET \
[Link]

Update Manual Entry Status


[POST] [Link]
Updates the status of specified manual entries. The IDs provided in the request
should match the ones returned by the GET request.

Request Parameters:
entry_ids (array of strings): The list of entry IDs to be updated (e.g., "550e8400-
e29b-41d4-a716-446655440000").

status (string): The new status to be applied ("approved" or "rejected").

Response Fields:
message (string): Confirmation message indicating the number of entries
successfully updated.

Example:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY_VALUE_HERE" \
--request POST \
--data '{ "entry_ids":["550e8400-e29b-41d4-a716-446655440000", "123e4567-e89b-12d3-
a456-426614174000"], "status":"approved" }' \
[Link]

Common questions

Powered by AI

To manage project-specific employee roles using the Teamlogger API, you can use the POST endpoint for adding and removing users from a project. The API allows assigning roles such as MANAGER or MEMBER to users via the endpoint [POST] https://api2.teamlogger.com/api/integration/add_user_to_project, which requires specifying the assignee's email, project name or ID, and desired role. Similarly, users can be removed with [POST] https://api2.teamlogger.com/api/integration/remove_user_from_project using the same parameters . However, for OPEN projects, there's a limitation: all employees automatically have access, so individual additions or removals are unnecessary, as the roles are universally applied .

The Teamlogger API enhances project flexibility and employee workload management by providing options for creating tasks with either individual or multiple assignees. The endpoint [POST] https://api2.teamlogger.com/api/integration/create_task allows tasks to be assigned to a single individual, enabling precise control and accountability . Meanwhile, the [POST] https://api2.teamlogger.com/api/integration/create_task_multi endpoint facilitates assignment to multiple assignees, promoting collaboration and shared responsibility among team members . This flexibility allows project managers to adapt task assignment to project needs, ensure balanced workloads, and foster teamwork, ultimately contributing to improved project outcomes.

The raw timesheet data and manual entry functionalities in the Teamlogger API complement each other by providing both automated and user-adjusted tracking of work hours. Raw timesheet data can be fetched using [GET] https://api2.teamlogger.com/api/timesheet_data, which offers a detailed log based on system-tracked time within specified start and end periods . Manual entries, on the other hand, allow employees to record time manually for specific tasks using [POST] https://api2.teamlogger.com/api/integration/add_manual_entry, providing flexibility to account for activities not captured automatically. This dual approach ensures comprehensive tracking, accommodating both scheduled and off-schedule work, thereby offering a full spectrum view of employee productivity .

Daywise grouping options in the Teamlogger API offer strategic advantages by allowing time-sensitive data analysis and providing insights into daily productivity and trends . This granularity helps project managers identify specific days where productivity may have been significantly higher or lower, enabling them to infer causes and adjust strategies accordingly. By understanding these trends, managers can notably enhance resource planning, uncover patterns associated with employee performance, and align project timelines with peak productivity periods, thus optimizing project management and improving overall efficiency.

Utilizing Unix timestamps in the Teamlogger API for time-related reports is significant as it provides a universal time reference that is both precise and consistent across systems. Unix timestamps represent time as the number of milliseconds since the UNIX epoch, ensuring that time data remains unaffected by time zone changes or localization issues . This consistency aids in integrating Teamlogger with other systems by offering a standardized time format, facilitating seamless data synchronization and analysis across different platforms. It also simplifies calculations, comparisons, and queries regarding time, enhancing data reliability and operational efficiency.

Generating a project summary report via the Teamlogger API requires specifying the start and end times of the summary in milliseconds since the UNIX epoch as mandatory parameters [GET] https://api2.teamlogger.com/api/project_summary_report?startTime=start_time_epoch_ms&endTime=end_time_epoch_ms . An alternative option to temporally group data daywise is also provided under different report endpoints, such as the Projectwise Employee Summary Report, where you can set the 'daywise' parameter to true to receive grouped data .

An organization might prefer the 'Projectwise Employee Summary Report' over the 'Employee Summary Report' in the Teamlogger API due to the granularity of data it offers. The 'Projectwise' report provides insights segmented by project, allowing managers to understand employee contributions and performance within the scope of specific projects . This can be critical for project-based organizations where assessing performance and resource allocation on a project basis is crucial for decision-making. It also facilitates the identification of high-performing projects and teams, enabling targeted improvements and strategic resource management.

The recommended process for synchronizing external IDs within the Teamlogger API involves using the designated POST endpoints to change external IDs for both projects and tasks. This capability ensures alignment with other systems integrated via external IDs. Use the endpoint [POST] https://api2.teamlogger.com/api/integration/change_project_external_id for projects, and [POST] https://api2.teamlogger.com/api/integration/change_task_external_id for tasks, to update these IDs . Synchronization is critical to maintain data consistency across systems and avoid errors or mismatches between different databases or platforms the organization relies on. It helps ensure that actions performed in Teamlogger correlate accurately with corresponding entities in external systems.

Failing to update task or project external IDs when using the Teamlogger API for system integration can lead to data mismatches, operational inefficiencies, and potential errors in tracking project and task activities across interconnected systems . This could result in synchronization issues, where updates in one system are not correctly reflected in another, leading to discrepancies in reporting, resource planning, or billing. To mitigate this risk, organizations should implement workflows to regularly update external IDs using the relevant API endpoints, ensuring that all systems involved reflect the most current information. This proactive data management approach supports data integrity across platforms.

When creating a project using the Teamlogger API, choosing between RESTRICTED and OPEN types has significant implications for user access permissions. An OPEN project allows all employees to access and work on it without needing specific assignment, thus simplifying access control in environments where all users need to contribute [POST] https://api2.teamlogger.com/api/integration/create_project . In contrast, a RESTRICTED project limits access to those explicitly assigned as MEMBERS or MANAGERS, providing controlled access and potentially enhancing security and order . This decision should align with the organization's needs for flexibility versus security in project engagement.

You might also like