# Menggunakan audit log Source: https://help.didit.me/id/account-organization/audit-logs Updated: 2026-10-29 Setiap permintaan API di organisasi Anda disimpan selama 365 hari: siapa, apa, kapan, dari mana, dan lewat aplikasi mana. Buka di Pengaturan, Log audit. Setiap permintaan API di organisasi Anda dicatat secara otomatis dan disimpan selama **365 hari** - baik dari konsol, integrasi Anda, maupun rekan tim Anda. Temukan di **Pengaturan → Log audit**. Setiap keputusan yang diambil Penyelidik sendiri juga dicatat di sana, atas nama **Penyelidik**. [Video: Log audit - Didit Academy](https://www.youtube.com/watch?v=MkULotdgz2o&t=31) ## Apa yang dicatat ![Audit log di konsol Didit yang menampilkan aktivitas API dengan timestamp dan kode status](https://help.didit.me/screenshots/audit-logs-light.webp) *Setiap permintaan API di organisasi, disimpan selama 365 hari.* Setiap permintaan yang dibuat ke platform Didit di dalam organisasi Anda, apa pun yang membuatnya. Setiap entri membawa: | Field | Detail | |---|---| | **Timestamp** | Kapan permintaan itu dibuat | | **User** | Siapa yang melakukannya: anggota yang membuat permintaan; untuk permintaan dengan API key, nama key tersebut dengan tag **API key**; **Didit** untuk hal yang dilakukan Didit sendiri; dan **Penyelidik** untuk keputusan yang diambilnya sendiri | | **Method** | GET, POST, PUT, DELETE | | **Path** | Endpoint yang dipanggil | | **Status** | Status respons HTTP | | **IP address** | Dari mana permintaan itu berasal | | **Application** | Aplikasi mana yang menjadi asalnya | Log disimpan selama **365 hari** lalu dihapus secara otomatis. Audit log yang didesain ulang, yang menjelaskan setiap perubahan dengan kata-kata dan bisa mengekspor apa yang sedang Anda lihat, sedang diluncurkan secara bertahap. Sampai tersedia untuk organisasi Anda, halaman ini menampilkan log permintaan yang dijelaskan di sini. ## Untuk apa sebenarnya ini digunakan Empat situasi di mana ini adalah alat yang tepat: - **"Siapa yang mengubah workflow ini?"** Sebuah alur yang berperilaku berbeda dari kemarin biasanya ada perubahan di baliknya, dan log menyebutkan siapa yang melakukannya. - **Menyelidiki sebuah insiden.** Melacak persis apa yang diakses, oleh siapa, dari alamat mana, dalam urutan apa. - **Men-debug sebuah integrasi.** Melihat permintaan yang benar-benar dibuat kode Anda sendiri, bukan yang Anda kira dibuatnya - termasuk yang menghasilkan error 4xx. - **Membuktikan kontrol akses.** Menunjukkan kepada auditor bahwa akses ke data verifikasi bersifat teratribusi dan bisa ditinjau. ## Memfilter Filter berdasarkan pengguna (anggota, API key, Didit, atau Penyelidik), endpoint, atau rentang tanggal untuk mempersempit daftar yang panjang. Ketika Anda sedang menyelidiki sesuatu yang spesifik, mulailah dari timestamp lalu bergerak keluar dari sana - sebuah permintaan jarang terjadi sendirian, dan panggilan-panggilan di sekitarnya biasanya menceritakan keseluruhan kisahnya. ## Permintaan dengan API key diatribusikan ke key, bukan ke seseorang Sebuah permintaan dengan API key tidak punya orang untuk diatribusikan, jadi yang ditampilkan adalah nama key tersebut. Itu adalah representasi yang jujur - platform ini sungguh-sungguh tidak tahu layanan atau engineer mana dari pihak Anda yang membuat panggilan tersebut. Konsekuensi praktisnya: satu key yang dibagikan ke beberapa layanan membuat sebuah insiden jauh lebih sulit diselidiki. Jika atribusi penting bagi Anda, beri setiap layanan key-nya sendiri. Lihat [mengelola API key Anda](https://help.didit.me/id/account-organization/api-keys). ## Keputusan Penyelidik sendiri diatribusikan kepada Penyelidik Saat Penyelidik memutuskan sendiri, dalam batas otonomi yang Anda berikan, entri tersebut menyebut **Penyelidik**, bukan seseorang atau sebuah key. Ini berlaku untuk setiap keputusan yang diambilnya: menyetujui atau menolak session atau meminta pengguna mengirimkannya ulang, menetapkan status transaksi, serta menyelesaikan kasus, mengeskalasinya, atau meminta informasi tentangnya. Setiap entri ini menautkan ke laporan Penyelidik di balik keputusan tersebut, sehingga Anda dapat melihat apa yang ditemukannya dan aturan kebijakan Anda mana yang diterapkannya. Saat seseorang memutuskan atas laporan Penyelidik, dengan menerima rekomendasinya atau menggantinya, entri tersebut diatribusikan kepada orang itu, sama seperti perubahan lain yang dibuatnya. Jejak lengkap Penyelidik, dengan laporan, pertanyaan, dan batas pengamannya, tetap ada di log **Aktivitas** miliknya sendiri. Lihat [Mengendalikan dan mengawasi Penyelidik](https://help.didit.me/id/investigations/investigator-automation-and-oversight). ## Apa yang ada di dalam log, dan apa yang tidak Log ini mencatat **aktivitas** - siapa memanggil apa, kapan, dari mana, dan status apa yang dikembalikan. Ini adalah jejak metadata, bukan salinan dari data verifikasi. Jika Anda perlu tahu apakah data pribadi pelanggan muncul di entri-entri ini - pertanyaan yang sering muncul selama tinjauan perlindungan data - dapatkan jawabannya dari kontak Didit Anda dan catat hasilnya, alih-alih menyimpulkannya sendiri dari sebuah halaman bantuan. Ini justru jenis pernyataan yang akan diminta DPIA Anda sendiri sebagai bukti. ## Siapa yang bisa melihatnya Akses audit log mengikuti peran. **Compliance Officer** mencakupnya; **Reader** tidak memiliki akses yang luas. Owner bisa memberikannya ke sebuah peran kustom. Lihat [mengundang anggota tim dan menetapkan peran](https://help.didit.me/id/account-organization/team-members-and-roles). Menghapus seorang rekan tim tidak menghapus riwayatnya dari log - dan memang itulah intinya. Sebuah jejak yang bisa Anda ubah bukanlah jejak. ## Ekspor dan laporan juga dicatat Membuat PDF session atau ekspor CSV adalah sebuah panggilan API, jadi itu juga muncul di sini beserta siapa yang membuatnya. Ini berguna ketika Anda perlu menunjukkan bahwa akses ke bukti verifikasi terkontrol, bukan terbuka bebas. Lihat [mengunduh laporan verifikasi](https://help.didit.me/id/verification-sessions/download-verification-report). ## Jika Anda butuh lebih dari 365 hari Retensinya tetap 365 hari. Jika kewajiban Anda lebih panjang dari itu, ekspor apa yang Anda perlukan secara terjadwal dan simpan di sistem Anda sendiri - pola yang sama seperti menyimpan sendiri bukti session. Menentukan periode yang diwajibkan adalah keputusan kepatuhan untuk tim Anda; jangan merancang berdasarkan asumsi. > **Note:** Retensi audit log dan retensi **data verifikasi** adalah pengaturan yang terpisah. > Mengonfigurasi jendela retensi yang singkat untuk data session tidak memperpendek > audit log, dan sebaliknya juga berlaku. Lihat > [bagaimana Didit melindungi data pengguna Anda](https://help.didit.me/id/data-privacy/how-didit-protects-data).