Report on Privacy Requests
Overview
The reporting feature allows you to fetch information about privacy requests. You can opt for high-level status information, or get more detailed information about the status of the requests on each of your collections.
View high-level statuses
This request displays concise, high-level information for all your privacy requests including their status and related timestamps.
Check out the API docs here.
GET api/v1/privacy-request | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
View a single privacy request
Use the id
query param to view the high level status of a single privacy request.
1 |
|
If an external_id
was provided at request creation, we can also track the privacy request using:
1 |
|
Please note: These parameters will return matching privacy requests based on startswith
matches.
Filtering options
Use the following query params to further filter your privacy requests. Filters can be chained, for example,
1 |
|
id
- status (one of
in_processing
,pending
,paused
,complete
, orerror
) created_lt
created_gt
started_lt
started_gt
completed_lt
completed_gt
errored_lt
errored_gt
You can filter for multiple statuses by repeating the status query param:
1 |
|
View privacy request logs
To view all the execution logs for a privacy request, visit /api/v1/privacy-request/{privacy_request_id}/logs
.
Embedded logs in the previous endpoints are truncated at 50 logs.
Check out the API docs here.
View a request's identity data
Use the optional include_identities
query param to include all identity data that was submitted for the Privacy Request. Due to the nature of how fidesops stores identity data, this data will expire automatically according to the FIDESOPS__REDIS__DEFAULT_TTL_SECONDS
variable.
If the identity data fetched by include_identities
has expired, an empty JSON dictionary will be returned.
View individual request log details
Use the verbose
query param to see more details about individual collections visited as part of the Privacy Request along
with individual statuses. Individual collection statuses include in_processing
, retrying
, complete
or error
.
You may see multiple logs for each collection as they reach different steps in the lifecycle.
verbose
will embed a “results” key in the response, with both audit logs containing information about the overall request,
as well as execution logs grouped by dataset name.
In the example below,
we have two datasets: my-mongo-db
and my-postgres-db
. There are two execution logs for my-mongo-db
(when the flights
collection is starting execution and when the flights
collection has finished) and two execution
logs for my-postgres-db
(when the order
collection is starting and finishing execution). fields_affected
are the fields
that were potentially returned or masked based on the Rules you've specified on the Policy. The embedded execution logs
are automatically truncated at 50 logs, so to view the entire list of logs, visit the execution logs endpoint separately.
There are also "Request approved" and "Request finished" audit logs included in the response.
GET api/v1/privacy-request?request_id={privacy_request_id}&verbose=True | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 |
|
Download all privacy requests as a CSV
To get all privacy requests in CSV format, use the download_csv
query param:
GET api/v1/privacy-request/?download_csv=True | |
---|---|
1 2 |
|
Paused or failed request details
A privacy request may pause when manual input is needed from the user, or it might fail for various reason on a specific collection.
To retrieve information to resume or retry a privacy request, the following endpoint is available:
1 |
|
Paused access request example
The request below is in a paused
state because we're waiting on manual input from the user to proceed. If we look at the action_required_details
key, we can see that the request
paused execution during the access
step of the manual_key:filing_cabinet
collection. The action_needed.locators
field shows the user they should
fetch the record in the filing cabinet with a customer_id
of 72909
, and pull the authorized_user
, customer_id
, id
, and payment_card_id
fields
from that record. These values should be manually uploaded to the resume_endpoint
. See the Manual Data
guides for more information on resuming a paused access request.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
Paused erasure request example
The request below is in a paused
state because we're waiting on the user to confirm they've masked the appropriate data before proceeding. The action_required_details
shows us that the request
paused execution during the erasure
step of the manual_key:filing_cabinet
collection. Looking at action_needed.locators
field, we can
see that the user should find the record in the filing cabinet with an id
of 2, and replace its authorized_user
with None
.
A confirmation of the masked records count should be uploaded to the resume_endpoint
See the Manual Data
guides for more information on resuming a paused erasure request.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
Failed request example
The below request is an error
state because something failed in the erasure
step of the postgres_dataset:payment_card
collection.
After troubleshooting the issues with your postgres connection, you would resume the request with a POST to the resume_endpoint
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|