# Terms and conditions

> A member accepts the STX terms personally, on an STX page. What your app sees when new terms take effect, and how to send the member to accept them.

Source: https://docs.stxapp.io/oauth/terms-and-conditions/

> **Availability.** Available on US demo now. Live access is coming soon in the US and Ontario. See [Environments](https://docs.stxapp.io/environments/).

A member accepts the STX terms and conditions personally, on an STX page, signed in to their own account. Your app never accepts them for a member, and no scope allows it.

## No scope accepts the terms

`terms.write` is retired. It can no longer be registered or granted, and it is not in `scopes_supported` of the [discovery document](/oauth/discovery-and-errors/). An authorize request that still lists it keeps working with its other scopes, and a token that once carried it simply no longer has it.

`POST /api/v1/tnc/accept` answers an app's token with `403`:

```json
{
  "error": "terms_not_delegable",
  "error_description": "An app cannot accept the terms for a member. Send the member to terms_url.",
  "terms_url": "<STX host>/connect/terms?client_id=<your client_id>"
}
```

## When a member connects

`/oauth/authorize` checks the terms for you. A member who has not accepted the current terms sees them on an STX page, with your app's name and logo, before the consent screen. Once they agree, the flow carries on and you get your `code` as usual, so a member you receive has accepted the terms STX had in effect. A new member accepts the terms when they register with STX.

If the member leaves that page with its "Back to" button instead of agreeing, you get `?error=terms_required` with your `state`, and no code.

Under `prompt=none` nothing can be shown. Where a returning member would otherwise get a `code` silently, one who has not accepted the current terms gets `?error=interaction_required` instead. Send them through `/oauth/authorize` without `prompt=none`. A Browser app or a Mobile or desktop app never gets a silent `code`, so it gets `consent_required` as before.

## When the terms change

STX publishes new terms from time to time. When a new version takes effect, a member who connected earlier has not accepted it yet. Their connection stays as it is:

- the grant, the access token and the refresh token keep working;
- reads keep working (profile, balance, positions, orders, history, WebSocket channels);
- cancelling orders keeps working, and orders already resting stay on the book.

What stops is placing new orders. `POST /api/v1/orders` and `POST /api/v1/orders/batched` answer `403`:

```json
{
  "error": "terms_required",
  "error_description": "The member has not accepted the current terms. Send the member to terms_url.",
  "terms_url": "<STX host>/connect/terms?client_id=<your client_id>"
}
```

You can also learn it before the member tries to trade. While the member has not accepted the current terms, every [refresh](/oauth/tokens-and-security/) response carries two extra members, `terms_required: true` and `terms_url`. The refresh itself succeeded and the tokens are good. Both members are absent when nothing is pending.

## Sending the member to accept

Open `terms_url` in the member's browser and add `return_to`, the page in your app they should come back to:

```
<terms_url>&return_to=https%3A%2F%2Fapp.example.com%2Faccount
```

`return_to` must be one of your registered redirect URIs, or an `https` page on the same origin (scheme, host and port) as one. Anything else is refused on the page and the member is not sent anywhere.

The member signs in to STX if they are not signed in already, reads the terms and agrees. STX records their acceptance and returns them to `return_to`. Then retry the call: it works, with the same tokens. If the member presses "Back to" without agreeing, they return to `return_to` as well and the call is still refused.

A member also sees pending terms whenever they are on STX for another reason: at login, during `/oauth/authorize`, and on the hosted [deposit page](/apps/hosted-pages/). So most members have already accepted by the time your app would need to ask.

There is no advance notice of a new version: `terms_required` appears once the new terms take effect, not before. It can take up to a minute after that moment to show on `/oauth/authorize`, API calls and refresh responses.

## Errors at a glance

| Where | What you get | Meaning | What to do |
| --- | --- | --- | --- |
| Redirect back from `/oauth/authorize` | `error=terms_required` | The member left the terms page without agreeing | Nothing was granted. Let them try again later |
| Redirect back from `/oauth/authorize` with `prompt=none`, where a `code` would have been silent | `error=interaction_required` | The member has to accept the current terms | Send them through `/oauth/authorize` without `prompt=none` |
| Placing an order | `403`, `error` `terms_required`, `terms_url` | The member has not accepted the current terms | Send the member to `terms_url` with your `return_to`, then retry |
| Refresh response | `terms_required: true`, `terms_url` | Same, and the refresh itself succeeded | Prompt the member when it suits your app |
| `POST /api/v1/tnc/accept` | `403`, `error` `terms_not_delegable`, `terms_url` | An app cannot accept the terms for a member | Send the member to `terms_url` |