> For the complete documentation index, see [llms.txt](https://developers.didomi.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.didomi.io/api-and-platform/consents/events/consent-event-approvals.md).

# Consent event approvals

By default, created events are confirmed: their `status` property has the value `confirmed`. This indicates that the event is valid and was applied to the user consent status.

Didomi supports various approval methods (email confirmation, email approval, etc.) where an event needs to be approved in a separate process before being applied to the user consent status. Such events are considered "pending" as they are created and stored in the API but not applied to the user consent status until the event is approved. Their `status` property is set to `pending_approval`.

When an event is updated to become `confirmed`, the Didomi API will automatically update the user consent status to apply the updated event. Events will be re-applied according to their update or creation date so that the most recent confirmed events will be applied last.

* [Create pending events](#create-pending-events)
* [Approve pending events](#approve-pending-events)

### Create pending events

Events are automatically created as pending if you use a validation method or a consent token with a validation method associated.

If you are not using a validation method and want to create pending events yourself, you can do so by specifying `pending_approval` in the `status` property:

```javascript
POST https://api.didomi.io/v1/consents/events?organization_id={organization_id}
{
  "status": "pending_approval",
  "user": {
    "organization_user_id": "{organization_user_id}"
  }
}
```

A pending event must include an `organization_user_id`. It also requires an event ID in the `id` property that will be automatically generated if you do not provide it.

### Approve pending events

The Didomi API supports three methods for approving pending events.

* [Approve pending events via validation methods](#approve-pending-events-via-validation-methods)
* [Approve pending events via API requests](#approve-pending-events-via-api-requests)
* [Approve pending events via an approval URL](#approve-pending-events-via-an-approval-url)

#### Approve pending events via validation methods

When a validation method is used, the approval process is entirely managed by the Didomi API through emails or similar methods. The Didomi API will also takes care of updating the event status when the event is approved through the validation method.

#### Approve pending events via API requests

If you are not using validation methods, you can manage the approval process yourself and approve pending events through API requests.

To approve pending events, update the event and set the `status` property to `confirmed` with a PATCH request:

```javascript
PATCH https://api.didomi.io/v1/consents/events/{event_id}
  ?organization_id={organization_id}
  &organization_user_id={organization_user_id}
  
{
  "status": "confirmed"
}
```

#### Approve pending events via an approval URL

When an event is in status `pending_approval`, an approval URL is added in the `validation.approve_url` property. Example of an event with an approval URL provided:

```javascript
{
  "user": {
    "organization_user_id": "user@domain.com",
    "metadata": {
      "custom_key": "value"
    }
  },
  
  "consents": {
    "purposes": [
      {
        "id": "purpose_id",
        "enabled": true
      }
    ]
  },
  
  "status": "pending_approval",
  
  "validation": {
    "approve_url": "https://api.privacy-center.org/consents/execute/..."
  }    
}
```

This URL can be used to easily approve the event without requiring API authentication and API calls. It is safe to embed in emails, webpages, etc. as links that users can click on to approve the event.

{% hint style="info" %}
You can attach metadata to the consent event and use it in the email template used to validate the pending consent. As an example, you create a `redirect_url` in the metadata and use it as an extra parameter to redirect your end-user on a relevant page for your brand after he approves the changes. ([See example here](/integrations/emailing/templates/templates.md#metadata-from-consents-events-to-email-templates))
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://developers.didomi.io/api-and-platform/consents/events/consent-event-approvals.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.