API, timeEntries zu user.id im Zeitraum

Developer Forum
1

Wir haben bei den Zeiteinträgen die wir via WebHooks erhalten immer wieder mal Differenzen.

Diese versuchen wir auszugleichen indem wir nachts alle Zeiteinträge des Tages abrufen und diese per Script nachpflegen. Es gibt dennoch immer wieder Abweichungen. Was ich gern tun würde, ist alle Zeiten eines Benutzers im Zeitraum ( z.B. letzer Monat) abrufen und mit unserer Datenbank vergleichen. Da gibt es gleich zwei Probleme/ Wünsche:

https://{{server}}/api/v1/users/{{userId}}/timeentries?filterby=createdOn gt datetime’2025-07-01T00:00:00’ and createdOn lt datetime’2025-08-01T00:00:00’ geht leider nicht, das geht aber derzeit schon bei Projekten:https://{{server}}/api/v1/projects/{{projectId}}/timeentries?filterby=createdOn gt datetime’2025-02-01T00:00:00’

Es gibt keine Summierungsformel wie z.B. bei SQL - oder sie ist mir nicht bekannt.

Danke für Tipps - Gruß Wolfgang vom account sven

2

Hi @Sven2, the URL you mentioned does not exist, that is correct, but you should be able to filter time entries by userId as well. Take a look at our developer docs here: Returns all time entries. | awork API | Documentation

https://api.awork.com/api/v1/timeentries?filterby=userId eq guid'123..'

I hope this helps.

3

Hi Sebastian,

thanks for your answer. This helps for maintenance. What is happening? We use webhooks to collect timeEntries for invoicing and controlling in a FileMaker Pro database - with a lot of other functionalities. From time to webhooks are paused - an we call time_entries of last day or last month etc. to keep them synced. The main problem is, that internal projects, running over a whole year, trigger more and more timemeentries, when something has been changed on it. That triggers hundreds of webhooks in seconds. Last time happened between 29.08.2020 18:20:00 and 18:20.32:

148 Webbhooks received our server in 30 seconds. Each of this webhook triggers a series of activity on our server. None of them was relevant for billing or controlling, none of then had an element wit changes. We only process timeentries_added or timeentries_changed when the changes-array contains “Duration”; “TypeOfWorkID” and “ProjectId” and “Note. Anyway - we have to retreive all this hooks before we can filter or process them to our system.
Message: “… an integration has been paused…” We already configured the Integration to use only events of first level . We did not have this problem as massive in 2023 an 2024.

Any hints?

4

Hi @Sven2 , did you enable the “First-level property events only” toggle for these webhooks? For convenience, awork provides a rich data model and we trigger webhooks also for changes to nested properties by default. This increases the number of events, but can be helpful to keep data in sync. If you do not need this, you can turn it off and drastically reduce the number of events you receive.

5

Yes, “First-level property events only” is activated.

6

@Sven2 if this is activated and you still receive this many webhook events, I would assume those are actual update events of first-level properties. Do you have any examples of events that you would not expect to receive, or need to discard?

7

OK, here is an object sent as webhook with entity_event: timetracking_updated without : Element „changes“ :{„timestamp“:„2025-09-05T17:30:00.8752762+00:00“,„eventType“:„timetracking_updated“,„entity“:{„isDateOnly“:true,„startDate“:„2025-06-30T22:00:00Z“,„endDate“:„2025-06-30T22:00:00Z“,„id“:„8c3f7dac-657e-4e91-80b7-658bc59e7375“,„createdBy“:„bce9624a-a0b9-ec11-997e-38563d6e6dce“,„createdOn“:„2025-07-01T07:30:40.5444868Z“,„updatedBy“:„c0ac8058-3349-ec11-981f-501ac527b592“,„updatedOn“:„2025-08-25T14:17:46.3209587Z“,„typeOfWork“:{„isArchived“:false,„icon“:„school“,„name“:„Medical Advice“,„id“:„bcef63a3-6e7e-4e0c-3266-08d9ddacefd6“},„user“:{„isExternal“:false,„firstName“:„…“,„lastName“:„…“,„hasImage“:true,„id“:„bce9624a-a0b9-ec11-997e-38563d6e6dce“},„task“:{„baseType“:„projecttask“,„taskStatusId“:„0043c86b-b9d2-4f23-997b-b0b13d63d24f“,„typeOfWorkId“:„bcef63a3-6e7e-4e0c-3266-08d9ddacefd6“,„project“:{„isPrivate“:false,„hasImage“:false,„isExternal“:false,„isBillableByDefault“:true,„createdBy“:„f25c2e7a-c25b-40a3-a3a0-81f8a317bdc0“,„projectStatus“:{„isArchived“:false,„type“:„progress“,„name“:„In Arbeit“,„id“:„20a8cb2f-ff2f-42bf-a927-4cda7b9eb7e2“},„company“:{„hasImage“:true,„description“:„“,„name“:„…“,„id“:„fe8bf823-7908-467a-8c06-821120bb997f“},„name“:„273011111 - …“,„id“:„1ff7fb5f-48d9-4eea-beef-00c3e36a735c“},„projectId“:„1ff7fb5f-48d9-4eea-beef-00c3e36a735c“,„plannedDuration“:14400,„totalPlannedDurationWithHierarchy“:0,„closedOn“:„2025-07-22T13:50:37.6756248Z“,„taskStatus“:{„order“:5,„icon“:„done“,„type“:„done“,„name“:„Erledigt“,„id“:„0043c86b-b9d2-4f23-997b-b0b13d63d24f“},„lists“:[{„orderOfTask“:-8.5,„id“:„369dd464-c461-4579-97c8-3310d6d3dac4“,„createdOn“:„2025-01-16T09:25:03.5706481Z“,„createdBy“:„01010001-0000-0000-0000-111111111111“,„updatedOn“:„2025-09-05T17:30:00.8750244Z“,„updatedBy“:„b1ea624a-a0b9-ec11-997e-38563d6e6dce“,„name“:„To-Do’s“,„order“:1,„plannedDuration“:0,„totalPlannedDuration“:137700,„totalPlannedDurationWithHierarchy“:137700,„isArchived“:false,„isHiddenForConnectUsers“:false}],„createdBy“:„c0ac8058-3349-ec11-981f-501ac527b592“,„correlationId“:„24cdb4ce-e598-492a-b3f1-cf76d275b014“,„parentId“:„24cdb4ce-e598-492a-b3f1-cf76d275b014“,„parentTask“:{„name“:„ESP1111 / Esanum / Messages 22.07. (ET 15.08.)“,„id“:„24cdb4ce-e598-492a-b3f1-cf76d275b014“},„primaryTaskListId“:„369dd464-c461-4579-97c8-3310d6d3dac4“,„name“:„…“,„id“:„532a5b2b-bdff-40e7-bfba-d0536eead590“},„project“:{„teams“:,„members“:,„isPrivate“:false,„createdBy“:„f25c2e7a-c25b-40a3-a3a0-81f8a317bdc0“,„isExternal“:false,„projectStatus“:{„isArchived“:false,„type“:„progress“,„name“:„In Arbeit“,„id“:„20a8cb2f-ff2f-42bf-a927-4cda7b9eb7e2“},„company“:{„hasImage“:true,„description“:„“,„name“:„…“,„id“:„fe8bf823-7908-467a-8c06-821120bb997f“},„name“:„…“,„id“:„1ff7fb5f-48d9-4eea-beef-00c3e36a735c“},„breaks“:,„resourceVersion“:638917282663209587,„isExternal“:false,„startDateUtc“:„2025-07-01T00:00:00Z“,„endDateUtc“:„2025-07-01T00:00:00Z“,„startDateLocal“:„2025-07-01T00:00:00“,„endDateLocal“:„2025-07-01T00:00:00“,„timezone“:„Europe/Berlin“,„duration“:900,„typeOfWorkId“:„bcef63a3-6e7e-4e0c-3266-08d9ddacefd6“,„userId“:„bce9624a-a0b9-ec11-997e-38563d6e6dce“,„isBillable“:true,„isBilled“:false,„taskId“:„532a5b2b-bdff-40e7-bfba-d0536eead590“,„projectId“:„1ff7fb5f-48d9-4eea-beef-00c3e36a735c“,„note“:„…m“},„entityId“:„8c3f7dac-657e-4e91-80b7-658bc59e7375“,„entityType“:„timetracking“,„entityLink“:„https://….awork.com/time-tracking/my-day/list",„traceId“:„c95eadd0c87ad98a8c68db406db9d941“,„triggeredBy“:{„id“:„b1ea624a-a0b9-ec11-997e-38563d6e6dce“,„firstName“:„…“,„lastName“:„…“},„subEntityType“:„task“,„subEntityId“:"532a5b2b-bdff-40e7-bfba-d0536eead590“}

8

Kleine Statistik :

▾ 2025-09-09:

•	5978 Hooks

▾	305 timetracking_added

	•	298 changes

	•	7 timetracking_added no changes  

▾	5668 timetracking_updated

	•	197  timetracking_updated changes

	**•	5471 timetracking_updated  no changes** ???

•	5 timetracking_deleted
9

Hi @Sven2 thanks for posting this. What I would need is the trace id of the request. It should be in the event metadata. This way I can look up what triggered this event that has no changes.

10

Hi Sebastian,

I Sent to you the content of one hooks stored in a record. of our database.

Thats what I can see.

Structure is:

  • awork webhooks are sent to –> “https://fmwebhooks.dto.de/hooks/aworkio/“ which is a proxy.
  • This proxy translates and processes the webhook to – > FileMaker Server’s data API.
  • FileMaker Server processes the content to our solution

Where do I find the ”trace id”?

11

The traceId should be a property in the event that you receive. I didn’t see one in the JSON you posted, was it removed somehow? I will check in the meantime if I can find it in any other way.

12

Hi @Sven2, we found the issue where those events would be sent even though the First-level property events only setting was enabled, and then potentially retried several times. We’re rolling a fix for this out, which should reduce the number of events significantly. Thanks for reporting this.