> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/feature-guides/security-and-governance/privacy-policy-acceptance.md).

# Privacy Policy Acceptance

The privacy policy acceptance is tracked per user. Each person accepts the privacy policy for themselves, and each person is re-prompted when a new version of the privacy policy is published. EULA acceptance is unchanged and remains organization-level.

### What Changed

|                                           | Before v1.102.0                | v1.102.0 and later                  |
| ----------------------------------------- | ------------------------------ | ----------------------------------- |
| EULA                                      | Accepted once per organization | Unchanged                           |
| Privacy Policy                            | Accepted once per organization | Accepted once per **user**          |
| New user joins an organization            | Never prompted                 | Prompted to accept                  |
| A new privacy policy version is published | One user accepted for everyone | Every user is prompted individually |

Acceptance follows the user, not the organization — if you belong to multiple organizations, you accept once and it applies everywhere. Nobody can accept on another user's behalf, including administrators.

### In the UI

If you have an unaccepted policy when you sign in, Bindplane shows a consent page before you reach the application. It lists what needs accepting with links to read each policy, and a single **Accept** covers everything outstanding.

The privacy policy must be accepted before an account is usable. If you consented on the sign-up form, that counts and you are not asked again; accounts created through SSO or invitation flows that did not capture consent are prompted at first sign-in.

### For the API and Automation

Whether your automation is affected depends on how it authenticates. The per-user check only applies to requests tied to an individual user.

| Authentication method                                             | Affected?                                       |
| ----------------------------------------------------------------- | ----------------------------------------------- |
| [Scoped API keys](/cli-and-api/scoped-api-keys.md)                | **No**                                          |
| Newer [API keys](/cli-and-api/api-keys.md) created without a user | **No**                                          |
| Legacy user-bound API keys                                        | **Yes** — gated on the user who created the key |
| Basic auth / direct user credentials                              | **Yes**                                         |

The organization-level EULA check applies to all of these, exactly as before.

Affected requests are rejected with HTTP status **`453`** until that user accepts:

```json
{
  "message": "policies must be accepted before using the API",
  "accept_endpoint": "PUT /v1/accept-policies",
  "unaccepted_policies": [
    "https://bindplane.com/legal/privacy-policy"
  ]
}
```

Handle `453` as "consent required" rather than as a generic failure. To clear it, call `PUT /v1/accept-policies` while authenticated as that user, or move the integration to a scoped API key so no user acceptance is involved.

{% hint style="warning" %}
Two cases are easy to miss. A **legacy API key** is gated on whoever created it, even if that person no longer uses Bindplane. A **service account** that only ever calls the API will start returning `453` when a new privacy policy is published, because an administrator can no longer accept on its behalf.
{% endhint %}

Self-hosted deployments started with `--accept-eula` (or `BINDPLANE_ACCEPT_EULA=true`) bypass the EULA and privacy policy entirely. This is unchanged.

### Upgrading

Each user inherits their organization's existing acceptance, so nobody is re-prompted at upgrade time. The next prompt comes when a new version of the privacy policy is published, and from then on each user accepts for themselves.

### Related Pages

* [Role-Based Access Control (RBAC)](/feature-guides/security-and-governance/role-based-access-control-rbac.md)
* [Single Sign-On (Cloud)](/feature-guides/security-and-governance/single-sign-on.md)
* [API Reference](/cli-and-api/api.md)
* [Scoped API Keys](/cli-and-api/scoped-api-keys.md)


---

# 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://docs.bindplane.com/feature-guides/security-and-governance/privacy-policy-acceptance.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.