Profile reprocessing API

Overview

The profile reprocessing API allows you to programmatically delete and re-ingest identity records for specific profiles. This enables you to handle GDPR deletion requests and correct misidentified profiles by triggering selective reprocessing of your identity graph.

Use cases

GDPR compliance: Process data deletion requests by removing specific identifiers from your identity graph.
Supercluster resolution: Reprocess profiles after identifying and blocklisting problematic identifiers that caused incorrect merging.

How it works

When you queue profiles for reprocessing, Hightouch:

Finds all profiles (ht_ids) containing the specified identifiers.
Deletes those profiles and their associated records from your IDR graph.
Re-ingests data from your connected source tables during the next IDR run.
Re-matches and re-merges profiles according to your active matching rules.

Important: Delete the relevant data from your source tables before calling this API. If the data still exists in your warehouse, it will be re-ingested during the next IDR run.

API reference

You can manage profile reprocessing programmatically using the following API endpoints:

These endpoints allow you to:

Queue identifiers for reprocessing or deletion.
Check the status of ongoing or completed jobs.
Integrate reprocessing logic into your GDPR or identity maintenance pipelines.

For full request and response schemas, authentication requirements, and example code snippets, visit the Hightouch API Reference.

Workflow

Delete source data — Remove relevant identifiers from your data warehouse tables that feed into IDR.
Queue for reprocessing — Submit a POST request to /idr/{graphId}/reprocess with the identifiers you want to remove.
Track the job — The API immediately returns a jobId for asynchronous processing.
Automatic reprocessing — During the next scheduled IDR run after the job completes, Hightouch deletes and re-ingests the affected profiles.

Processing timeline

The queuing and marking of identifiers happen asynchronously after you call the API.
Actual deletion and re-ingestion occur during the next IDR run after the job finishes.
Expect one full IDR run cycle to see changes reflected in your resolved identity tables.

Best practices

Delete source data first: Ensure any personal or incorrect data is removed from your warehouse before triggering reprocessing.
Track your jobs: Save jobId values for audit and debugging purposes.
Batch identifiers: For efficiency, include multiple identifiers in a single request when processing bulk deletion requests.
Verify results: After the next IDR run, confirm that reprocessed profiles have been correctly deleted or updated in your identity graph.