---
Source: https://docs.microblink.com/platform/transaction-consent
Title: Get users' consent
Description: Configure and manage user consent for identity verification transactions
---

# Get users' consent

You need end-user consent to process a transaction.
If it's not given, you cannot progress through the workflow.
Consent is always transaction-scoped, meaning each new transaction will require a new user consent.

:::note[Regions]

Code examples here use the `us-east` region. Use the appropriate [region](/platform/api/overview#region) for your deployment.

:::

## Structure

Consent is defined as the following structure:

```json
{
  "userId": "unique-value-representing-end-user",
  "givenOn": "2025-01-02 03:04:05.678",
  "ipAddress": "192.168.1.1",    // automatically collected & anonymized
  "userAgent": "Mozilla/5.0...", // automatically collected
  "note": "notes, comments",
  "isProcessingStoringAllowed": true,
  "isTrainingAllowed": true
}
```

- `userId` is a required field. This value should uniquely represent the end user
  within the system. The platform uses it to automatically group that user's
  transactions into a [user profile](/platform/api/user-profiles).
- `givenOn` is an optional field describing when the consent was collected. If it's
  not provided, the current timestamp is assigned.
- `ipAddress`, `userAgent`: Automatically assigned by the platform.
- `note` is a text field available to customers to further explain the consent if
  needed.
- `isProcessingStoringAllowed` **must be set to true** to proceed with the
  transaction. This value represents that the account owner has collected this
  end-user's consent for their data to be processed and stored by Microblink. Their
  consent is required for us to be able to complete the verification.
- `isTrainingAllowed` is optional and will not block the transaction if not given.
  However, when set to true, transaction-level data may be used to further improve
  the platform. This value represents that the account owner has collected this
  end-user's consent for their data to used by Microblink for the improvement of the
  fraud detection capabilities in our own products.

## Submit the consent

You can submit user consent via multiple channels.

### At the start of transaction

When a new transaction is started, you can immediately provide the consent for it.

```json
{
  "workflowId": "8cL5xg63gbzLSjvUWYBm9Hnv", 
  "platform": "browser", 
  "sdkVersion": "1.3.0",
  "consent": {
    "userId": "my-user-55d02c8f-28c9-4ae1-aec8-6cdaf78101be",
    "isProcessingStoringAllowed": true,
    "isTrainingAllowed": true
  }
}
```

In this case, the consent is provided by the app on the user's device. The SDK code
in the app contacts your [proxy](/platform/proxy) and simultaneously starts a transaction
**and** provides consent.

:::important[What if you don't send consent on transaction creation?]

If you don't send consent when you create a transaction, the SDK code in your app will ask the user to provide the consent. 
This may cause user experience issues or inconsistencies, which is why we **recommend you always provide consent whenever you create a transaction.**

We cannot process an end user's information without having their consent. 
If you do not provide it, we must collect it ourselves. 
Therefore, if your app already included a consent collection pop-up, collect the consent for this processing as well, and then provide it on each transaction creation.

:::

### As a separate API call

If transaction was already created without a consent, you can submit the consent
payload separately:

```json
{
  "userId": "my-user-55d02c8f-28c9-4ae1-aec8-6cdaf78101be",
  "isProcessingStoringAllowed": true,
  "isTrainingAllowed": true
}
```

In this case, the app (SDK) doesn't go through the proxy and doesn't contact the Agent API.
Instead, it provides consent directly to the [Edge API](/platform/api):

```http
https://api.us-east.platform.microblink.com/edge/api/v1/transaction/{transaction_id}/consent
```

### Using verification links

[Verification links](/platform/api/verification-links) allow deferred transaction creation.
As this process automatically creates the transaction when the link is opened, you can send the consent at that point.

```sh
curl --url https://api.us-east.platform.microblink.com/agent/api/v1/verification-link --user "$CLIENT_ID:$CLIENT_SECRET" --json '{"...","consent":{"userId":"my-user-55d02c8f-28c9-4ae1-aec8-6cdaf78101be","isProcessingStoringAllowed":true,"isTrainingAllowed":true}}'
```

## Partial submission

You can also send consent *partially*: send individual fields in different requests, optionally by using multiple of the methods above.
Only the latest values are used on the back end.

However, once `isProcessingStoringAllowed` is `true`, it **cannot be reverted** to `false`, as the transaction might have already been executed.

## Retrieve the consent

### Request

```
GET /agent/api/v1/transaction/{transaction_id}
```

For example:

```sh
curl --url https://api.us-east.platform.microblink.com/agent/api/v1/transaction/{transaction_id} --user "$CLIENT_ID:$CLIENT_SECRET"
```

### Response

```json
{
    "id": "0267bdb133715dc60d70f49703",
    // ... cropped for readability
    "consent": {
      "userId": "unique-value-representing-end-user",
      "givenOn": "2025-01-02 03:04:05.678",
      "note": "free text",
      "ipAddress": "34.66.222.0",
      "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36",
      "isProcessingStoringAllowed": true,
      "isTrainingAllowed": true
    },
    // ...
}
```

In the IP address field, the last octet is always `.0`, as platform does not store the full IP address at any point.

## Best practices for notification, consent, and data retention

### Privacy notices

Before collecting consent, provide clear privacy notices that are easily discoverable and use plain language accessible to your target audience.[^1]
Your privacy notice should include:

- Controller identity
- Specific processing purpose
- Data types collected
- Retention period
- Third-party sharing details

You can use or adapt the Microblink privacy notices available at:

- [Privacy notice for Platform users](https://microblink.com/privacy-notice-for-microblink-platform-users/)
- [Privacy notice for end users](https://microblink.com/privacy-notice-for-microblink-customers-end-users/)

### GDPR-compliant consent standards

Obtain explicit opt-in consent through active checkboxes or buttons—never use pre-ticked boxes.[^2]
Enable easy consent withdrawal mechanisms that are as simple as granting consent, ensuring users can change their preferences at any time.

### Identity verification transparency

Clearly explain why identity documents and biometric data are collected.
Detail the document scanning, authenticity checks, and liveness detection procedures your end users will experience.

### Data retention

Define clear retention periods based on legal requirements and business needs:[^3]

- Typically 3-5 years for identity verification data under AML/KYC compliance
- Immediate deletion of biometric data after verification unless legally required

The platform has customizable data retention with a minimum retention period of 3 months and a default setting of 36 months.
Automated deletion permanently removes data when retention periods expire.

### Regional compliance

Store data in appropriate jurisdictions based on customer location.
Implement adequate safeguards for cross-border transfers through Standard Contractual Clauses, adequacy decisions, or Data Privacy Framework mechanisms.
Adapt retention periods to meet specific regional requirements, including state biometric laws.

### Documentation and audit trails

The platform documents when, how, and for what specific purposes consent was obtained.
This includes timestamps, dates, and consent context to create verifiable audit trails for regulatory inspections and end-user rights requests.

Track and respond to data subject rights requests within GDPR's 30-day timeline.

### Jurisdiction considerations

Displaying a privacy notice to the end customer is mandatory in most jurisdictions.
Certain jurisdictions also require publication of retention schedules—check if the jurisdiction of your interest has this requirement.
Additionally, some regulations require written consent for specific data types (e.g., CPRA requires written consent for biometric data processing).

[^1]: (EU/UK) GDPR art. 12-14; (Canada) PIPEDA Principles 2-3; (Brazil) LGPD art. 6-7, 9; (China) PIPL art. 17-21; (California) CPRA §1798.100(b), §1798.110, §1798.121; (Colorado) CPA §6-1-1307, §6-1-1308; (Virginia) CDPA §59.1-574, §59.1-575

[^2]: (EU/UK) GDPR art. 4, 6, 7; (Canada) PIPEDA Principle 3; (Brazil) LGPD art. 7-8; (China) PIPL art. 13-17; (California) CPRA §1798.120; (Colorado) CPA §6-1-1306; (Virginia) CDPA §59.1-574, §59.1-575

[^3]: (Illinois) BIPA art. 15(a)


Last updated on Apr 23, 2026