https://[yoursubdomain].zendesk.com/api/v2/access_logs?filter[start]=2022-03-01T00:00:00Z&filter[end]=2022-03-12T00:00:00Z

filter[start] - should be older date

filter[end]   - should be later date 

{
"access_logs": [
{
"timestamp": "2022-03-11T00:10:34Z",
"user_id": 12345,
"ip_address": "00.00.000.85",
"url": "/api/services/access_logs",
"method": "GET"
},
{
"timestamp": "2022-03-11T00:13:38Z",
"user_id": 12345,
"ip_address": "00.00.000.85",
"url": "/api/services/access_logs",
"method": "GET"
},
{
"timestamp": "2022-03-11T00:14:02Z",
"user_id": 12345,
"ip_address": "00.00.000.85",
"url": "/api/services/access_logs",
"method": "GET"
}
    ]
}

filter[start] - UTC Time stamp in format of yyyy-mm-ddThh:mm:ssZ
filter[end]  - UTC Time stamp in format of yyyy-mm-ddThh:mm:ssZ 
filter[path] - URL path. excluding query params.

https://subdomain.zendesk.com/api/v2/access_logs?filter[start]=2022-08-01T15:04:05Z&filter[end]=2022-08-02T20:04:05Z&filter[path]=/api/v2/ticket_fields

 filter[start] - UTC Time stamp in format of yyyy-mm-ddThh:mm:ssZ
 filter[end]  - UTC Time stamp in format of yyyy-mm-ddThh:mm:ssZ
 filter[user_id]  - Number. Valid userID

https://subdomain.zendesk.com/api/v2/access_logs?filter[start]=2022-08-01T15:04:05Z&filter[end]=2022-08-01T20:04:05Z&filter[user_id]=12345678

 filter[start] - UTC Time stamp in format of yyyy-mm-ddThh:mm:ssZ
 filter[end]  - UTC Time stamp in format of yyyy-mm-ddThh:mm:ssZ

https://subdomain.zendesk.com/api/v2/access_logs?filter[start]=2022-08-01T15:04:05Z&filter[end]=2022-08-01T20:04:05Z

• Comentario oficial

  Caroline Kello

  • 23 de marzo de 2022 21:22

  Zendesk Product Manager

  Currently known limitations of the EAP

  • A large part of our frontend uses a tool called GraphQL. For the purposes of this EAP it  means that the URL path is obfuscated and we don’t know what was accessed as part of the request an agent made. You will see this /graphql path in some of the URLs. 
  • If your account moves pods at any point during this beta, you’ll lose access to the information and events that were created when you were on the old pod will not be copied over. 
  • There are still some parts of the product that we can’t gather information from; Explore, Sell etc. 

   

• Caroline Kello

  • 29 de abril de 2022 17:55

  Zendesk Product Manager

  Added a new bullet point to the Additional information section that calls out that the API supports cursor-based pagination.

• Dan Cooper

  • 11 de mayo de 2022 20:15

  Community Moderator

  Would this also show us when Zendesk employees access our data via account assumption or otherwise?

• Caroline Kello

  • 23 de mayo de 2022 22:16

  Zendesk Product Manager

  Hi Dan, apologies for the delayed response. I've not tested this myself but I assume that as a Zendesk employee accesses the account as another user, any action they take is logged as being taken by the user they accessed as. This is true for how events are captured in the Audit log today, and should also be true for the Access log. 

• Chester Hansen

  • 20 de junio de 2022 21:24

  Hi Caroline,

   

  I have a question about /graphql results. 
  
  I see that there is a "graphql" property when that is the end point that is being accessed. This shows the query, name, type, and variable. which is great. However, is there a way to see the result of the query? For further context, we plan to pipe the logs into a longterm storage with the ability to query and filter later if needed so we have access longer than the 90 days of Zendesk. We are wanting to have a record of when an agent access customer data. getting just a query, while it does provide base and entry level information we are not able to view exactly what information they were able to see at the time of the event. For example, when an agent accesses a ticket the graphql give the variable of the ticket Id, but i do not know what customer if any is the requester to that ticket. If the behavior is slightly different when they go to a customer profile vs a ticket that would be a great thing to have documentation around we we can get a better idea of exactly is being accessed without needing to blindly open tickets based on the id alone. If we are able to see the results directly within the access log itself, or at the very least the ID of each object that is returned from the query
  
  example: we query tickets with an ID: 12345, the assigneeID is 14567, the requester id is 4567889 and the follower ids are [123,456,789], etc
  
  That will give us dramatically more actionable information increasing the usability of the api dramatically.

   

  I would be happy to jump on a call sometime to better explain our use case and desired outcomes.

• Caroline Kello

  • 22 de junio de 2022 16:41

  Zendesk Product Manager

  Hi Chester, thanks so much for this detailed feedback. Let me pass it on to the team first for a quick check but I'll definitely take you up on the offer to chat as well. 

• Caroline Kello

  • 22 de junio de 2022 18:51

  Zendesk Product Manager

  As a initial reaction we're hesitant to add this information for two reasons: a) the query result could be massive and we've not investigated the feasibility of adding this type of load, and b) this would add PII to our internal logs that we've also not investigated the impact of. 

  I'll keep the discussion going with the team but there's a bunch of investigation and due diligence that would be needed for us to understand if this is feasible. 

• Shigeichi Nakano

  • 24 de junio de 2022 03:55

  Hi, We seems to have some cases that logs cannot be found while the target APIs would be called internally. For example, when I opened an end user or an organization from agent workspace, I assume that an API (e.g. /api/v2/users/<id> or /api/v2/organizations/<id>) should be called, but nothing can be found in access log. Regarding to tickets and help center articles, we can find which data has been accessed by analyzing GraphQL log.
  Is this a current limitation of functionality, or do I miss something?

• Caroline Kello

  • 1 de agosto de 2022 23:16

  Zendesk Product Manager

  HI Shigeichi, apologies for the delayed response! We currently have a dependency on one of our internal services to supply accountID and userID headers; this is why the information isn't showing up for you. Current timeline for getting this resolved is end of August so I'll be back with an update for you then. 

• Caroline Kello

  • 5 de agosto de 2022 17:54

  Zendesk Product Manager

  Updated the documentation to outline the supported filters; by user, by object and by timestamp.

• Rusty Wilson

  • 1 de mayo de 2023 13:08

  Hi Caroline Kello! Thanks for the information so far.

  The intro paragraph says, "...captures what an agent has accessed in your account". Are there any plans to capture what *users* are doing?

  Do *light agents* count as *agent* activity that gets captured?

• Caroline Kello

  • 3 de mayo de 2023 17:48

  Zendesk Product Manager

  Hi Rusty,

  We've currently no plans on extending this to capture end-user access events. What are some of the activity you'd like to see there? And what would you use that information for?

  We didn't have Light Agent included in our original requirements, but we also didn't put any specific restrictions in place that would exclude them. I'll need to test this to confirm if it's captured - I'll be back once I have more information and I can update our EAP documentation at that point. 

• Rusty Wilson

  • 3 de mayo de 2023 18:17

  Hi Caroline Kello - thanks for the prompt and courteous reply. I was thinking really "edge case" stuff - like a user getting accidental escalated privileges and information that would be helpful in a security audit of such an event. Clearly not an "everyday" need and hopefully a never need. :)
  
  I have a couple additional questions I'd love your insight on when time permits:

  1. Are "Light Agent" activities available as well as the "full" agent activity?
  2. Is the data available via this API the same as what's found in the audit log in the admin interface? If not, in what way is it different?

• Caroline Kello

  • 3 de mayo de 2023 19:11

  Zendesk Product Manager

  Ah, so if an end-user were to have their role set to that of a agent? That's something we already have events for in the Audit log. 

  1. If this is for the question if Light Agent activity is captured in the Access log, I'll get back to you on this. 

  2. There main answers you'll be able to get from the Access log is who viewed a ticket, who viewed a user profile, and what searches did an agent make (including the search term). This is not information that's currently available in the Audit log. I look at the Audit log as your record of Create, Update, Delete, Sign in events - and the Access log is your record of Read events. 

Iniciar sesión para dejar un comentario.