live redact api

role

Feature

client

Cover

year

2025

Objective

During my return internship at Cover this Spring, I got the chance to work on a feature called Live Redact which can take files/data from various sources and in various different formats and return them with any user-defined target information either overtly or covertly removed. There were several substantial challenges that I had to take into account when designing this feature.

Design Requirements

1. Redactions need to be reliable - there is a very low margin of error tolerable given the nature of the project

2. Latency has to be kept extremely low - the distinguishing feature of Live Redact is that it can serve as a streaming API. If it's not Live, then it defeats the purpose of using it.

3. The API has to handle multiple input types seamlessly, and it has to deal with inconsistencies (i.e different resolutions, different formatting, etc.) within inputs of the same format.

4. The service has to integrate with other features by Cover or integrations to third-party services hooked up by the customer. It has to function as a node in the context of a larger system.

Design Summary

Without going into too much detail, the basic design of the API had to

Decipher input type, deal with any invalid input types and make formatting adjustment to deal with potential inconsistencies in inputs that might cause issues
Run necessary scans to identify targets matchng user-provided descriptions using an in-house model (latency & security constraints make use of external APIs unfeasible)
Implement appropriate redaction measures at identified target sites
Return data to Cover client or external node, with all proper error handling measures

Results

I was able to get the API up and running with a high degree of reliability, though it took me substantially longer than I expected. You can read further @ Cover

Conclusion