Developer Guide | Allies Comply

Quick start

Widget quick start

The Comply widget is a JavaScript snippet you add to any page on your site where you want users to be able to submit data requests. Typically this is your privacy policy page or a dedicated "Your data" page.

Find your business ID. Log in to your Comply dashboard, go to Settings, and copy the business ID shown there.
Add a container element. Place a div with an ID on the page where the widget should render.
Add the script tag. Paste the code below before your closing </body> tag. Replace YOUR_BUSINESS_ID with your actual ID.

<!-- Container element -->
<div id="allies-comply-widget"></div>

<!-- Add before </body> -->
<script
  src="https://allies.gg/allies-comply-widget.js"
  data-business-id="YOUR_BUSINESS_ID"
></script>

That is all you need for the widget to appear and start accepting requests. The widget handles the form, email verification flow, and submitting the request to Comply's backend. No backend changes are required on your end.

Identifiers

What the widget captures

When a user submits a request, the widget collects their name and email from the form, plus a few technical identifiers silently in the background. Here is what gets captured and why each one matters for finding that person's data.

Email address

The primary identifier. Comply searches your database for any record where a column contains this email address. Most user tables store emails, so this is usually the most powerful lookup.

IP address

Captured from the request. Some databases log IP addresses against user sessions or activity records. Comply uses the IP to search those columns, which can surface records not directly tied to an email.

User-agent string

The browser and device signature. Like IP addresses, some systems log user-agents. Including this as a search identifier means Comply can find records in analytics or session tables that only track device signatures.

Session cookies

If the user has session cookies set by your domain, the widget captures the cookie values present at submission time. This helps link the request to any session IDs stored in your database, which is particularly useful for finding records where the user was not logged in.

Note on anonymous data: Even with all these identifiers, some tracking data cannot be reliably linked to a specific person. Cookies get cleared, IPs change, and device signatures are shared across household members. Your dashboard will prompt you to manually check systems Comply cannot reach. See the compliance guide for more on this.

Configuration

Configuring the widget

The widget only has two configuration options. There is no complex API surface here by design.

Attribute	Required	Description
`data-business-id`	Yes	Your unique business identifier. Found in the dashboard under Settings.
`data-target`	No	The ID of the element where the widget should render. Defaults to `allies-comply-widget`. Do not include a `#` prefix.

The widget renders itself into the target element. It handles loading, form display, submission, and confirmation states internally. You do not need to write any event handlers.

Database

Database connection

Connecting a database is what enables automatic scanning. Without it, Comply routes requests to your dashboard but cannot find or delete data for you.

Supported databases

PostgreSQL (any version supporting information_schema)
MySQL 5.7 and later

Required permissions

Create a dedicated database user for Comply. Grant that user:

SELECT on all tables that you want Comply to scan. This is needed for both the schema scan and the request scan.
DELETE on tables where Comply should be able to delete rows.
UPDATE on tables where Comply should be able to anonymize fields (replace personal data with a placeholder).

Tables you mark as "protected from deletion" in the dashboard do not need DELETE or UPDATE grants, even if Comply can see them during a scan.

Principle of least privilege: Only grant DELETE and UPDATE on tables where you actually want Comply to make changes. For tables you want to scan but never modify, SELECT alone is sufficient.

SSL

SSL is required by default. Comply will not connect to a database without an encrypted connection unless you explicitly disable the SSL requirement in the integration settings. Only disable SSL for local development environments.

How Comply reads schema information

Comply uses information_schema to enumerate all tables and columns. It also reads foreign key constraints from the schema to understand how tables relate to each other. This is how it knows to follow a user row to that user's orders, comments, and other related records. No special schema setup is required on your end.

Scanner

How the scanner works

There are two distinct scan modes: the schema scan and the request scan. They run at different times for different purposes.

Schema scan

The schema scan runs once when you first connect a database, and again whenever you trigger a rescan. It classifies every column in your database as one of four categories: personal data, may contain personal data, needs review, or no personal data.

Classification uses two signals. First, column name heuristics: a column named email_address is obviously personal data, while created_at is obviously not. Second, value sampling: for columns where the name is ambiguous, Comply reads up to 50 random values and looks for patterns like email format, phone number patterns, IP address patterns, and so on.

Sampled values are never stored. Only the resulting classification is kept.

Request scan

When a user verifies their request, Comply runs a request scan using the identifiers captured by the widget: email, IP, user-agent, and session cookies. It searches every column classified as personal data or may-contain-personal-data for matches.

When it finds a match, it also follows foreign key relationships up to two levels deep. So if it finds a matching user row, it will also find that user's orders, comments, preferences, and any other table that references the user by ID.

For each matching record, Comply proposes an action based on the request type and your settings. Delete requests get a default proposal of "delete row" for most records and "anonymize fields" for protected-adjacent records. View requests compile the data for display.

Execution

When you accept a request, Comply executes all the proposed actions in a single database transaction. If any step fails, the entire transaction rolls back. On success, the changes are committed and the user is notified.

Security

Credential encryption

Database credentials are encrypted using AES-256-GCM before being stored. Each set of credentials gets its own randomly generated initialization vector. Allies staff cannot read credentials in plaintext. Credentials are decrypted only in memory at runtime, when a connection is needed.

Value sampling

During the schema scan, Comply samples up to 50 random rows from uncertain columns to detect personal data patterns. Those values are processed in memory and immediately discarded. Only the classification result (personal, uncertain, no-personal, needs-review) is stored. Comply does not build a copy of your data.

What Allies can and cannot see

Allies can see: your schema structure (table names, column names), classification results, request metadata (requester name, email, request type, status), and execution logs.

Allies cannot see: your database credentials in plaintext, the actual data values in your database (beyond the transient sampling described above), or personal data belonging to your users outside of the request fulfillment workflow.

Troubleshooting

Scan stuck in "pending" forever

A schema scan that never completes usually means Comply cannot connect to your database. Check that the credentials are correct, the database host is reachable from the internet, and your firewall allows inbound connections from Comply's IP ranges. Also confirm SSL settings match your database configuration.

Connection failed error

Verify the host, port, database name, username, and password in your integration settings. Common mistakes: using a local hostname like localhost (Comply is not on your local network), a missing port, or a database name that is different from the username. Also check that the database user has been granted at least SELECT on the tables you want scanned.

No data found for a request

This can happen for a few reasons. The user's email might not match anything in your database (they may have signed up with a different address). The schema scan may have missed the relevant columns if they have unusual names. Try adjusting the confidence threshold toward aggressive in Settings and running a rescan. Also confirm the relevant tables have SELECT grants for the Comply database user.

Widget not showing up

Check the browser console for errors. The most common issue is a typo in the container selector: container: '#allies-comply-widget' will fail silently if no element with that ID exists on the page. Also confirm the script tag loads before the AlliesComply.init() call, and that both are placed before </body>.

Integrate Comply in about 10 minutes