# End-user consent

When your users (consumers, in Vault terms) connect their accounting, HRIS, CRM, or other system through Apideck, they are authorizing you to access their data. You own that relationship and the legal basis for it. This guide covers what to put in front of your users and how to word it.

> **Not legal advice**
>
> This page explains how Vault fits into a consent flow and what other customers commonly cover in
> their own terms. It is not legal advice. Consult your own counsel to determine what consent,
> disclosures, and terms are required for your product, your users, and the jurisdictions you
> operate in.

## Who is responsible for what

Data ownership and control depend on the connected account and your business model — an individual consumer authorizing access doesn't necessarily own everything in that system. In most integrations you (the customer) are the data controller and Apideck acts as your processor, but confirm this matches your own setup; if you're acting on behalf of your own customers in a different capacity, the roles can shift. Apideck's data handling, including what is and isn't retained, is set out in the [Data Processing Agreement](https://compliance.apideck.com/dpa); see [Zero Data Retention](https://www.apideck.com/zero-data-retention) for background on the underlying architecture.

Getting valid consent from your user is your responsibility. [Vault](/guides/vault) gives you the mechanism. Your terms and privacy policy should explain the applicable legal basis, but do not establish that basis by themselves — the consent mechanism in your product flow does.

## What to show before opening Vault

If you enable [Data Scopes](/guides/data-scopes-for-accounting), Vault shows the consumer a **Requested Data Access** prompt after authorization, listing the exact fields your app requests, with Accept or Deny. Accepting is the consumer's consent to those specific fields — it is not consent to your product's purpose for the data or how long you keep it, which still need your own words.

![Requested Data Access prompt shown to the consumer when Data Scopes are enabled](/guides/data-scopes/grant-scopes-to-hris.png)

You can also pass your own terms and privacy policy links into the Vault session itself, so they render as links in the Vault sidebar, via `theme.terms_url` and `theme.privacy_url` on [session creation](https://developers.apideck.com/apis/vault/reference#operation/sessionsCreate):

```json meta=Example
{
  "theme": {
    "vault_name": "Acme",
    "terms_url": "https://acme.com/terms",
    "privacy_url": "https://acme.com/privacy"
  }
}
```

That covers the links, but purpose text — what you're reading, why, and what happens on disconnect — still needs your own words, shown before you hand the consumer the [Vault session URL](/guides/authorize-connections). Customers commonly cover:

1. Which system is being connected and which data types you will read or write (for example invoices, contacts, payroll).
2. What you will do with that data and why.
3. That the connection is established through a third-party infrastructure provider, with a link to your privacy policy and subprocessor list — some customers name Apideck specifically here, others cover it only in their subprocessor list; check what your own disclosure obligations require.
4. That the user can disconnect at any time from inside your product, and what happens to already synced data when they do.

Many customers also require an explicit action, such as a checkbox against their privacy policy, before the connect button is enabled. Enable Data Scopes with the minimum fields you use, so the prompt in Vault matches what your terms say. Keep the copy short — users who understand exactly what they are sharing are more likely to connect.

> **Example copy**
>
> "Connect your accounting system to sync invoices and payments into [Product]. We read invoice,
> customer, and payment data. We do not modify records in your system. This connection is
> established through a third-party integration provider. You can disconnect at any time in
> Settings. See our [Privacy Policy]."

This example is read-only. If your app uses write scopes, add a clause covering what you create or update in the connected system.

## What to cover in your terms

- **Data ownership**: the user retains ownership of data in their systems.
- **Authorization scope**: connecting a system is consent to access the listed data for the stated purpose.
- **Service providers**: you use third-party processors, potentially including Apideck, named in your subprocessor list.
- **Controller and processor roles**, and the DPA that governs them — confirm which role applies to your own business model.
- **Revocation**: how to disconnect and the effect on synced data.
- **Retention and deletion**: how long you keep synced data and how the user requests deletion.
- **Third-party platform terms**: the connected system's own terms continue to apply.

## After the connection

Store the consent record (who, when, which scopes). Give users a way to see and revoke [connections](/guides/connection-states) in your UI. When a connection is revoked or a token expires, tell the user and stop syncing. If the same connection powers more than one feature, check before you delete data that another feature still needs.

## Related

- [Vault](/guides/vault)
- [Authorize Connections](/guides/authorize-connections)
- [Vault Connection States](/guides/connection-states)
- [Data Processing Agreement](https://compliance.apideck.com/dpa)
- [Trust Center](https://compliance.apideck.com/)
- [Subprocessor list](https://compliance.apideck.com/subprocessors)
- [Privacy Policy](https://compliance.apideck.com/privacy-policy)
- [Zero Data Retention](https://www.apideck.com/zero-data-retention)