--- title: "Get customer flex control" method: GET path: "/v1/customers/{customerId}/flex-controls/{flexControlId}" tags: ["Customer flex controls"] --- # Get customer flex control `GET /v1/customers/{customerId}/flex-controls/{flexControlId}` Get a flex control, given the `customerId` and `flexControlId`. NOTE: This endpoint requires an account-specific access token. ## Path parameters - `customerId` number, required - `flexControlId` string, uuid, required ## Response `200` OK. Flex control was found. - CustomerFlexControlsResponse — Flex control response. - `id` string, uuid, required — Flex control ID is auto-generated at creation time. - `type` 'authentication' | 'challenge-request', required — Evaluation intention - `processing_codes` ProcessingCodes — Object with the processing codes for credit and debit operations - `credit` string — Processing code that identifies the credit operation - `debit` string — Processing code that identifies the debit operation - `rule_reference_id` string — ID of program-level flex control. Only present in generic flex controls created for the entire program. - `name` string — name - `account_id` integer, required — Account ID - `customer_id` integer — Customer ID - `card_ids` number[] — Card ID list - `currency_code` string — ISO 4217 3-letter currency code, For example, `986` = Brazilian real and `840` = US dollar. - `max_limit` integer — Maximum spending limit. Once met or exceeded, any subsequent transactions are declined by evaluation control flow. Note that this value is an integer. Since global currencies vary in the number of digits that are allowed after the decimal point, you must convert the actual maximum spending limit into an integer value to use in this field. To do this, use the following formula. value = floatNumber × 10^X, where X is the number of digits after the decimal separator for the currency as defined in ISO 4217. For example, if you want to set the value 499.99 for BRL currency transactions, where the number of decimal places is 2, you must set it to `49999` (499.99 × 10²). If you want to set the value 499 for JPY currency transactions, where the number of decimal places is 0, you must set it to `4999` (4999.0 × 10^0 = 4999.0 × 1 - in other words, the value doesn't change.) This field is **REQUIRED** for cumulative controls. - `max_transactions` integer — Maximum number of transactions allowed. Once met or exceeded, subsequent transactions are declined by the evaluation control flow. - `max_amount` integer — Maximum accumulated amount allowed. Once met or exceeded, subsequent transactions are declined by the evaluation control flow. Note that the value must be calculated as follows. value = floatNumber × 10^X, where X is the number of digits after the decimal separator for the currency defined in ISO 4217. For example, if you want to set the value 499.99 for USD currency transactions, where the number of decimal places is 2, you must set the value to `49999` (499.99 × 10²). If you want to set the value 499 for JPY currency transactions, where the number of decimal places is 0, you must set the value to `499` (499.0 × 10^0 = 499.0 × 1 - in other words, the value doesn't change). - `limit_duration` string — Flex control limit period duration (ISO 8601 format). For example, if a flex control sets a spending limit of $500, and `limit_duration` is set to one month (`P1M`), then the user cannot spend more than $500 from the account in any one month period. If `limit_duration` is not set, then the flex control does not accumulate. - `reset_datetime` string, date-time — Reset datetime (RFC-3339 format). If `reset_datetime` is not set, by default it will calculated based on `limit_duration` period and the current time. - `time_zone` string — IANA Time Zone database, such as "America/New_York". This attribute is used to evaluate the flex control using the desired time zone for condition attributes such as `week_day`, `month_day`, `time_now`, and `reset_period`. If `time_zone` is empty, the control is evaluated using the UTC time zone. - `reset_period` ResetPeriod — Enables the specification of reset periods for accumulators based on the duration in `limit_duration`. When this field is set, it must follow the RFC 3339 pattern from ISO 8601. When `reset_period` changes, the `avaliable_limit` is reset. - `month_day` number — Month day to reset. Can only be used when `limit_duration` is monthly. - `month` number — Numeric day of the month to reset the flex control. Can only be used when `limit_duration` is yearly. - `week_day` 'monday' | 'tuesday' | 'wednesday' | 'thursday' | 'friday' | 'saturday' | 'sunday' — Week day to reset. Can only be used when `limit_duration` is weekly. - `time` string — Time to reset flex control in time zone defined by control. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `utc_time` string — *Note: This field has been deprecated, use `time` instead.* Time to reset the flex control in the UTC 0 time. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `reset_strategy` ResetStrategy — The strategy to reset the accumulators. - `reset_trigger` object — Trigger that resets the accumulators - `is_password_present` boolean — Indicates whether the client entered a password - `is_pin_validated_offline` boolean — Indicates whether the pin was validated offline, triggering a reset of the accumulator when true - `authentication_method` string[] — Indicates which authentication methods should trigger a reset of the flex-control accumulator. - `available_limit` integer — Total available limit to spend, calculated by: max_limit - current_spend_limit. The `current_spend_limit`, an internal field, is the total amount of all approved transactions in the `limit_duration` period. It is reset by the evaluation flow when a new transaction is evaluated in the new period according to the `reset_datetime`. When `available_limit` is set in a PATCH request, it resets `current_spend_limit`. In this case, `available_limit` cannot be greater than `max_limit`. Note that `available_limit` is an integer. Since global currencies vary in the number of digits that are allowed after the decimal point, you must convert the actual maximum spending limit into an integer value to use in this field. To do this, use the following formula: value = floatNumber * 10^x, where x is the number of digits for the currency as defined in ISO 4217. For example, if you want to set the value 499.99 for BRL currency transactions, you must set 49999 = 499.99 * 10^2. On the other hand, the Japanese money system does't use fractions of a yen (the Japanese currency). So, to set the value at 4999 yen, you must set 4999 = 4999.0 * 10^0 = 4999.0 * 1. (In other words, the value doesn't change.) - `conditions` Condition[] - `type` 'INSTALLMENT_NUMBER' | 'PROCESSING_CODE' | 'ACCOUNT_TYPE' | 'ORIGIN' | 'DCC' | 'DOMESTIC' | 'MERCHANT_NAME_LIST' | 'INSTALLMENT_PLAN' | 'AMOUNT' | 'MERCHANT_CATEGORY_CODE' | 'REVERSAL_INDICATOR' | 'AUTHORIZATION_FLOW' | 'ORIGINAL_PROCESSING_CODE' | 'MTI', required — List types and data formats allowed: - `INSTALLMENT_NUMBER` - Integer values - `PROCESSING_CODE` - Alphanumeric strings - `ACCOUNT_TYPE` - Alphanumeric strings - `ORIGIN`- Alphanumeric strings - `DCC`- Boolean values - `DOMESTIC`- Boolean values - `MERCHANT_NAME_LIST` - Alphanumeric strings - `INSTALLMENT_PLAN` - Alphanumeric strings - `AMOUNT` - Numbers with or without decimal places - `MERCHANT_CATEGORY_CODE` - Alphanumeric strings - `REVERSAL_INDICATOR` - Boolean values - `AUTHORIZATION_FLOW` - Either `PAYMENTS` or `NETWORK` - `ORIGINAL_PROCESSING_CODE`- Original processing code or persisted authorization processing code - `MTI` - Message Type Indicator (MTI) - a four-digit numeric field - ISO 8583 standard - `operator` 'eq' | 'neq' | 'gt' | 'gte' | 'lt' | 'lte' | 'in' | 'contains' | 'starts_with' | 'ends_with', required — Operator that will be used on this rule evaluation - `eq`: Equals operator, allowed with rules that evaluate data containing strings, numbers, and booleans. - `neq`: Not equals operator, allowed with rules that evaluate data containing strings, numbers, and booleans. - `gt`: Greater than operator, allowed with rules that evaluate data containing numbers. - `gte`: Greater than or equal operator, allowed with rules that evaluate data containing numbers. - `lt`: Less than operator, allowed with rules that evaluate data containing numbers. - `lte`: Less than or equal operator, allowed with rules that evaluate data containing numbers. - `in`: In operator, allowed with rules that use model list as data. Compares if the data is in the configured list. - `contains`: Contains operator, allowed with rules that use model list as data. Compares if the data is part of any string in the configured list. - `starts_with`: Starts with operator, allowed with rules that use model list as data. Verifies whether any string in the list starts with the data value. - `ends_with`: Ends with operator, allowed with rules that use model list as data. Verifies whether any string in the list ends with the data value. - `data` string, required — Data used to evaluate this rule against the operator and the information received in the request. This field must be in the format as indicated in `type` and `operator`. **Note:** This field's value can be a model list ID returned from [Create model list](https://developers.pismo.io/pismo-docs/reference/post-org-model-list). A model list contains a list of values for evaluation. - `active` boolean — Is the program calendar strategy active? - `deny_code` string — Deny code related to restriction. This code is returned when the evaluation does not meet the conditions. - `response_code` string — Network two-digit response code. For example: 00 = approve, 51 = insufficient funds, 57 = card not active, 96 = system failure, etc. For more information, see [Validation codes for authorization events](https://developers.pismo.io/pismo-docs/docs/validation-codes-for-authorization-events). If `approve` = `false`, you can use this value to respond to the network. - `custom_code` 'FL2' | 'FL8' | 'FLB' | 'FLE' | 'DCM' | 'VMN' | '998' | 'LUD' | 'LUE' | 'LUT' | 'LGE' | '810' | 'PFT' | 'IAT' | 'BND' | 'ANF' | 'CTE' | 'CED' | 'ZBD' | 'FRB' | 'UBT' | 'FL6' | 'BNF' | 'BNP' | 'BNR' | 'VED' | 'BNU' | 'VEV' | 'UBN' | 'CSU' | 'NPL' | 'OP1' | 'TNF' | 'Z26' | 'Z24' | 'Z29' | 'Z23' | 'Z22' — Internal custom code generated in authorization flow for declined requests, indicating the reason the request was declined. For more information, see [authorization validations](https://developers.pismo.io/pismo-docs/docs/validation-codes-for-authorization-events#authorization-validations). - `evaluation_order` integer — Order in which the control is evaluated. If this value is not provided, the control is evaluated after the controls with the configured `evaluation_order` value. - `card_mode` 'credit' | 'debit' — Specifies the operational mode of the card. - `customized` boolean — Indicates whether the flex control is managed by the user. If `customized` is `false`, the flex control is managed by the card's program. Generally speaking, users shouldn't change flex controls created by the program, however it is possible to do so. You can reverse indivdually managing a flex control with a call to [Update account flex control](https://developers.pismo.io/pismo-docs/reference/patch-v1-accounts-flex-control) or [Update customer flex control](https://developers.pismo.io/pismo-docs/reference/patch-v1-customers-flex-control) and setting `customized` as `false`. ## Other responses - `400` — Bad request. Validation error on request. - `403` — Forbidden. Authorization error on request. - `404` — Not found. Flex control for customerId not found. - `500` — Internal server error. --- [API](https://skmtc.net/pismo/apis/platform-authentication.md) · [All operations](https://skmtc.net/pismo/apis/platform-authentication/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/pismo/platform-authentication/versions/935b62e16de4/schema)