Skip to main content
De audit log geeft je een fraudebestendige historie van de acties die je medewerkers in je account uitvoeren: wie wat deed, aan welke resource, vanwaar en of het is gelukt. Gebruik hem om wijzigingen te onderzoeken, aan compliance-eisen te voldoen en vragen te beantwoorden zoals “wie heeft die order geannuleerd?” of “wanneer is dit menu-item bijgewerkt?”.
De audit log is beperkt tot account owners en admins. Medewerkers met andere rollen zien een “restricted”-bericht wanneer ze hem proberen te openen, en een admin wiens toegang is beperkt tot bepaalde stores ziet alleen events voor die stores.

​
Waar te vinden

1

Open Logs

Klik in de zijbalk op Analytics om de sectie uit te klappen en selecteer vervolgens Logs.
2

Open de Audit Log

Selecteer onder de kop Security de optie Audit Log.
3

Zoek en filter

De meest recente events worden automatisch geladen. Beperk de resultaten met filters of exporteer wat je ziet naar CSV.

​
Wat wordt vastgelegd

Elke entry legt de volledige context van één medewerker-actie vast: Een rij selecteren opent een detailpaneel met de request-methode, het pad, de route, het IP-adres, de user agent, request-ID en trace-ID, samen met het fouttype als een actie mislukt is.

​
Welke acties worden vastgelegd

  • Alle wijzigingen worden vastgelegd — alles wat data creëert, bijwerkt of verwijdert (inclusief acties zoals archiveren, annuleren, herstellen of publiceren).
  • Gevoelige reads worden vastgelegd — het bekijken of downloaden van rapporten, exports, facturen en statements. Het openen van de audit log zelf wordt vastgelegd als een read, en het exporteren ervan als een export.
  • Routine-reads (lijsten bladeren, detailweergaven openen, polling op de achtergrond) worden niet vastgelegd, zodat de log gericht blijft op betekenisvolle activiteit.
Acties door klanten die orders plaatsen en door API-keys vallen buiten het bereik van de audit log — deze focust op medewerker-acties in het dashboard.

​
Wie heeft wanneer een store-instelling gewijzigd

Het opslaan van een pagina met store-instellingen wordt net als elke andere wijziging vastgelegd: een update op de resource achter die pagina, toegewezen aan de medewerker die heeft opgeslagen en met een tijdstempel van het moment waarop. Openingstijden zijn het meest voorkomende geval. Wekelijkse openingstijden en Special Opening Hours worden samen opgeslagen via Save in Stores → jouw store → Settings → Opening Hours, dus beide komen aan als één entry met resource type hour en actie Update.
1

Filter op wijzigingen aan openingstijden

Klik op Add filter, kies Resource type, voer hour in en klik op Apply. Voeg het Action-filter toe ingesteld op Update, en het Outcome-filter ingesteld op Success — mislukte opslagacties worden ook gelogd en die hebben niets gewijzigd.
2

Stel het datumbereik in

De log opent op de laatste 30 dagen. Om het te beperken, klik op de datumbereik-knop met het kalenderpictogram rechts van de filters en kies een preset (Today, Yesterday, This month, Last month, This year, Last year, All time) of selecteer de datums in de kalender. All time laat niets zien buiten je bewaartermijn.
3

Lees de rij

Time is wanneer de openingstijden zijn opgeslagen, Actor is de medewerker die ze heeft opgeslagen (naam, e-mail en rol op dat moment) en Store is de betrokken store — je kunt het Store-filter dus achterwege laten en in plaats daarvan de kolom lezen in plaats van store-IDs op te zoeken.
4

Klap uit voor de request-details

Als je de rij selecteert, zie je Path als /venues/<store id>/hours, het IP address, de User agent en het Request ID, en Fields changed als venueHours en specialHours.
Dezelfde aanpak werkt voor andere wijzigingen — filter op resource type (venue voor de eigen instellingen van een store, en menu, product of discount-code voor wijzigingen aan catalogus en promoties) en lees de kolommen Actor en Time.

​
Wat dit je niet vertelt

  • De waarden. De log legt vast dat openingstijden zijn gewijzigd en welke velden erbij betrokken waren — nooit de tijden vóór en ná. Er is geen manier om de vorige openingstijden in het dashboard te bekijken.
  • Wijzigingen die niet door een medewerker zijn gemaakt. Alles wat door een API-key, een POS- of bezorgintegratie, of een klant is gedaan, valt buiten het bereik.
  • Alles wat ouder is dan je bewaartermijn. Standaard 30 dagen (zie Bewaartermijn).
Als een wijziging ouder is dan je bewaartermijn, of door een integratie is gemaakt, kan de audit log je niet vertellen wie hem heeft gemaakt. Neem contact op met support met de store en de geschatte datum als je hem alsnog wilt laten onderzoeken.

​
Zoeken en filteren

De audit log gebruikt een facetzoekbalk. Voeg één of meerdere filters toe en klik op Apply; actieve filters verschijnen als verwijderbare pillen. Beschikbare facetten: Standaard toont de log de laatste 30 dagen. Resultaten zijn gepagineerd — gebruik Load more om oudere events op te halen. Je kunt alles wissen met Clear all.
Combineer facetten om in te zoomen op een incident — filter bijvoorbeeld op Actor en Action: delete om alles te zien dat een specifieke gebruiker heeft verwijderd.

​
Exporteren naar CSV

Klik op Export om de momenteel gefilterde resultaten als CSV-bestand te downloaden (met dezelfde filters en datumbereik). Handig om te delen met auditors of om buiten storekit te archiveren.
Exports zijn gemaximeerd op 50.000 rijen. Als je deze limiet bereikt, verklein je het datumbereik of voeg je filters toe en exporteer je in kleinere batches.

​
Privacy en dataverwerking

De audit log is ontworpen om vast te leggen wat er is gewijzigd zonder gevoelige inhoud vast te leggen:
  • Hij slaat de namen van de velden op die bij een wijziging betrokken zijn (bijv. “price, availability”) — nooit de daadwerkelijke waarden die zijn ingediend.
  • Veldnamen die er gevoelig uitzien (wachtwoorden, tokens, keys, kaartgegevens, PIN’s en dergelijke) worden automatisch verwijderd en nooit vastgelegd.
  • Records zijn append-only: entries worden nooit bewerkt of individueel verwijderd, waardoor de historie betrouwbaar blijft.

​
Bewaartermijn

Audit-entries worden standaard 30 dagen bewaard, en de log opent op datzelfde 30-daagse venster. De bewaartermijn wordt per account ingesteld, dus accounts die een langere historie nodig hebben voor compliance kunnen die aanvragen.
Alleen account owners en admins. Andere medewerkerrollen kunnen hem niet bekijken of exporteren.
De log legt bewust alleen wijzigingen en gevoelige reads (rapporten, exports, facturen, statements) vast. Dagelijkse browsing en achtergrondrequests worden uitgesloten zodat de log gericht blijft op betekenisvolle activiteit.
Nee. Hij legt vast welke velden bij een wijziging betrokken waren, maar niet de ingediende waarden. Namen van gevoelige velden worden helemaal weggelaten.
Entries worden standaard 30 dagen bewaard. Als je een langere bewaartermijn nodig hebt voor compliance, neem contact op met ons team.
Je kunt de gefilterde resultaten exporteren, tot 50.000 rijen per export. Voor grotere bereiken kun je de export in kleinere datumvensters opsplitsen.