API Request Tracing And Data Storage Policy

API audit trail and debugging made simple

Introduction

Attestr assigns a unique request tracing Id to every API request made on the platform. This makes it possible for Attestr to keep track of each client's usage, as well as to uncover potential platform bugs and troubleshoot customer problems.

Generate and Access Request Tracing ID

Request Tracing ID is automatically generated on each API request made to the platform. This ID is formatted as a long hexadecimal string, which is then included in the response headers, as per the format defined below.

{

  ......

  'xattestrid': '85c66edb-be2e-4e21-93f4-84c1f19bb0f5',

  ......

}

To access the Request Tracing ID on Postman, switch to Headers Tab in the response section as shown below and look for xattestrid to get the corresponding value.

Storing Tracing ID

While storing the Tracing ID in database is optional, it is generally a good practise to store for the following two reasons.

1. For reporting issues to Attestr
2. For report generating and invoice reconciliation

Tracing ID can either be stored in a persistent storage like database or in a temporary storage such as log files. Attestr recommends storing tracing ID in persistent storage.

Using Tracing ID For Reporting Issues

Attestr maintains a 30 day rolling log of all API requests made to the platform which includes key metadata about the request. This includes information such as request tracing ID, Org ID, request timestamp, time taken to process the request, associated error stack trace and other important parameters needed to understand and analyse the API behaviour.

While reporting issues to Attestr, it is mandatory to quote the tracing ID for a Root cause analysis (RCA).

Using Tracing ID to track usage

Attestr offers easy to download transaction reports in CSV format using the dashboard. The transaction log thus downloaded contains the Request Tracing ID as one of the column values which can be used to track the usage over a period of time. In order to download a report, login to Attestr Dashboard and select Reports from the left navigation menu as shown in the image below.

Here is a sample transaction log report file for reference.

Data Storage Policy

By default, all API requests made to Attestr are logged and persisted in the database. The stored information typically includes:

• Request Metadata – such as unique request identifier, timestamp, service name, and API client ID.
• Input Data – the request payload submitted by the client.
• Verified Output Data – the processed and validated response generated by Attestr.

This storage mechanism serves two primary purposes:

1. PDF Report Generation – enabling accurate and traceable report creation for each verification request.
2. Transaction Reconciliation – allowing auditability, tracking, and operational accuracy in billing and reporting.

Flexible Storage Option with XAttestrSkipStore Header

To provide additional control to platform users, Attestr supports a custom request header:

When this header is included and set to true in the API request:

• Verified Output Data is not stored in the Attestr database.
• Only minimal request metadata is stored, including:
  • Request unique identifier
  • Input data
  • Timestamp
  • Service name
  • API client ID

This feature ensures that while the request traceability is maintained, sensitive response data is not persisted, thereby offering more privacy-conscious handling of verification results.

curl --location --request POST 'https://api.attestr.com/api/v2/public/checkx/rc' \

--header 'Authorization: Basic <API Token>' \

--header 'Content-Type: application/json' \

--header 'XAttestrSkipStore: true' \

--data-raw '{

    "reg": "KA01MB1673"

}'

Data Deletion Policy

Attestr respects the right of its customers and end-users to request deletion of their data. Upon receipt of a valid written request, Attestr will permanently delete all data associated with the requesting customer or specific user from its systems, subject to applicable legal, regulatory, or contractual obligations. All such deletion requests must be submitted in writing to contact@attestr.com. Once a request is verified and processed, the data will be securely and irreversibly removed within a reasonable timeframe, and a confirmation of deletion will be provided.

Data Deletion Workflow

1. Request Submission

   • Customers or authorized users submit a written deletion request to contact@attestr.com.
   • The request must clearly specify the data subject (customer account or specific user).

2. Verification of Identity and Authority

   • Attestr verifies the authenticity of the request and validates whether the requester is authorized (e.g., account owner or designated admin).
   • If required, Attestr may seek additional documentation to confirm authority.

3. Request Acknowledgement

   • A confirmation email is sent acknowledging receipt of the deletion request, along with an estimated timeline for processing.

4. Data Identification and Isolation

   • All data linked to the specified customer or user is identified across active systems, backups, and reporting logs.
   • Where possible, data is isolated to prevent further use during the deletion process.

5. Data Deletion Execution

   • Verified data is securely and irreversibly deleted from production systems.
   • Metadata required for audit or reconciliation (e.g., transaction IDs, timestamps) may be retained in anonymized or non-identifiable form.

6. Validation and Audit Logging

   • A final verification is conducted to ensure all requested data has been deleted.
   • An audit log of the deletion event (excluding deleted content) is securely maintained for compliance.

7. Final Confirmation to Requester

   • Attestr provides a written confirmation to the requester once the deletion is successfully completed.

INTERESTED ?

To start a chat, click the button below, and one of our available executives will assist you with questions about onboarding and commercials.

Chat with support