---
title: "Enroll or Unenroll a Customer in an Account Feature"
method: PUT
path: "/programs/{programCode}/accounts/{accountIdentifier}/features/{featureId}"
tags: ["VIPFeature"]
---

# Enroll or Unenroll a Customer in an Account Feature

`PUT /programs/{programCode}/accounts/{accountIdentifier}/features/{featureId}`

· Enroll or Unenroll a Customer into or from an Additional Account Feature.<br>· Negative Balance:   The Negative Balance feature is available to be used by Partners. This feature can only be requested during onboarding.<br>·  Feature ID: NB100 – Negative balance $100 feature code.  Depending on the terms and conditions included in the daa that is accepted during account registration, some features may need to be explicitly accepted via the PUT /accounts endpoint.  Initially, all programs will be configured to not enforce terms acceptance.  Once the system is configured to enforce terms acceptance for a feature, any customer that does not accept the terms for that feature will not be allowed to use the feature.  For any programs, where customers are already using features that may require explicit terms acceptance, a data backfill will be required for those customers prior to enforcement being enabled.  Please work with your Green Dot Account Manager and/or Product Manager to understand the impact and transition plan for your program and features.<br>· UCB 1 – 4:  UCB tiers are cash back reward tiers based on program setup. These features are mutually exclusive. For example, if a customer is enrolled in UCB 1, then they cannot be enrolled in UCB 2, 3, or 4.<br>  However, a customer can be enrolled in NB100 and a UCB feature. For example, NB100 and UCB 2.<br>· Remote Check Deposit Tiers (RCDTier):   Check Deposit Tiers are required to use MRDC and to manage MRDC hold periods on an account.<br>· CDTiers are mutually exclusive, meaning an account can only be enrolled in one CDTier at a time.<br>· Call PUT /accounts/{accountIdentifier}/features/{featureId} to assign a CDTier to an account.<br>

## Path parameters

- `programCode` string, required
- `accountIdentifier` string, required
- `featureId` string, required

## Headers

- `X-GD-RequestId` string, required

## Request body

- UpdateFeatureRequest — Represents a request to update the authorization status of a specific VIP feature for an account. Inherits standard request metadata from Gd.Bos.DataTransfer.Request.RequestBase.
  - `authorize` boolean, nullable — Gets or sets a value indicating whether the feature should be authorized. Serialized as "authorize" in the request payload.

## Response `200`

OK

- UpdateFeatureResponse — Represents the response returned after a feature is updated. Inherits standard response metadata and details from Gd.Bos.DataTransfer.Response.ResponseBase.
  - `responseDetails` ResponseDetail[], nullable — Required: A list of response details providing status codes, descriptions, and additional information about the result of the operation.
    - `code` integer — The primary status or error code for the response (e.g., 200 for success, 400 for validation error).
    - `subCode` integer, nullable — An optional subcode providing more granular detail about the response or error.
    - `description` string, nullable — A human-readable description of the response, error, or status.
    - `url` string, nullable — A URL linking to documentation or a web page with more information about the response code.

## Other responses

- `401` — Unauthorized
- `403` — Forbidden
- `500` — Internal Server Error
- `503` — Service Unavailable

---

[API](https://skmtc.net/greendot/apis/baas-apis.md) · [All operations](https://skmtc.net/greendot/apis/baas-apis/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/greendot/baas-apis/revisions/666553766b78/schema)