Elastic Path Custom Fields API

A Custom Field represents a single field of data (for example a Product Rating). A Custom API is composed of one or more Custom Fields. Here is a comparison of different types and validation available in Custom APIs vs Non-Core Flows. | Feature | Non-Core Flows | Commerce Extensions | |-----------------------------------------------|----------------|--------------------------------------------| | Data Type: String | ✅ | ✅ | | Data Type: Integer | ✅ | ✅ | | Data Type: Float | ✅ | ✅ | | Data Type: Boolean | ✅ | ✅ | | Data Type: List | ⛔ | ✅ | | Data Type: Any | ⛔ | ✅ | | Data Type: Date & Time | ✅ | ✅ Replaced by Regex Validation (See Below) | | Data Type: One To Many | ✅ | Planned | | Validation: Regular Expression | ⛔️ | ✅ | | Validation: Slug/Email | ✅ | ✅ Replaced by Regex Validation (See Below) | | Validation: Min/Max Value | ✅ | ✅ | | Validation: Enum(String) | ✅ | ✅ Replaced by Regex validation (See Below) | | Validation: Enum(Float/Integer) | ✅ | ⛔️ | | Validation: Allow null values | ⛔ | ✅ | | Validation: Unique(String) | ⛔ | ✅ | | Validation: Unique Case Insensitivity(String) | ⛔ | ✅ | | Validation: Immutable | ⛔ | ✅ | ## Validation When [creating](/docs/api/commerce-extensions/create-a-custom-field#request) or [updating](/docs/api/commerce-extensions/update-a-custom-field#request) a Custom Field, `validation` can be used to limit the values that may be stored in the corresponding Custom API Entry. :::note All validation changes, such as those to `allow_null_values` and any type specific rules, apply to new entries only. Existing Custom API Entry records are unaffected until updated. ::: ### Integer Validation - `min_value`: Specifies the minimum whole number that can be stored. If set, it must be less than `max_value`. - `max_value`: Specifies the maximum whole number that can be stored. If set, it must be greater than `min_value`. sample integer validation object: ```json { "validation": { "integer": { "min_value": 0, "max_value": 32 } } } ``` Even if no validation is set, field_type `integer` only supports values between -2^53+1 and 2^53+1. This is because the JSON format doesn't guarantee that values outside this range are portable ([Source](https://datatracker.ietf.org/doc/html/rfc7159#section-6)). ### Float Validation - `min_value`: Specifies the minimum number that can be stored. If set, it must be less than `max_value`. - `max_value`: Specifies the maximum number that can be stored. If set, it must be greater than `min_value`. sample float validation object: ```json { "validation": { "float": { "min_value": 0.01, "max_value": 32.01 } } } ``` The `float` field_type cannot accurately represent some numbers and so using very small or large numbers might lose precision. We recommend that API clients use either the `integer` field_type if applicable , or the `string` data type if perfect precision or recall is required. ### String Validation - `min_length`: Specifies the minimum number of characters that can be stored. If set, it must be greater than 0 and less than `max_length`. - `max_length`: Specifies the maximum number of characters that can be stored. If set, it must be greater than 0 and `min_length`. - `regex`: An [RE2](https://github.com/google/re2/wiki/Syntax) regular expression used to restrict the specific characters that can be stored. It must be less than 1024 characters. - `unique`: Specifies whether the field must have unique constraint or not. It must be `yes` or `no`. - `unique_case_insensitivity`: Applies when `unique` is set to `yes`. It controls whether values with different cases (for example, `ABC` and `abc`) should conflict. It must be `true` or `false`. sample string validation object: ```json { "validation": { "string": { "min_length": 0, "max_length": 64, "regex": "^.+\\.(jpg|jpeg|png|gif|pdf)$", "unique": "yes" "unique_case_insensitivity": true } } } ``` Even if no validation is set, field_type `string` only supports values that are up to `65535` characters long. #### Date & Time Values With Regular Expressions While Commerce Extensions does not have a native date or time type, you can none-the-less use these values in Commerce Extensions, by using the `string` field type and `regex` validation. To ensure that ordering is handled properly you should follow the guidance in [RFC 3339 - Section 5.1 Ordering](https://www.rfc-editor.org/rfc/rfc3339.html#section-5.1), namely store the fields in order of least to most precise, and in the same timezone, this will ensure that comparison operators (e.g., `gt`) and sorting, work as expected, for example the following regex will force all values to be in seconds in UTC: `^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$` One thing to keep in mind is that some libraries, especially when dealing with sub-seconds might only display them if they are non-zero, and you will want to ensure that they are fully padded to the same length. #### Enum Values with Regular Expressions You can ensure that only some values are allowed using the regular expression `^(alpha|bravo|charlie)$`. #### Slug Values with Regular Expressions Slugs can be replaced with the regular expression `^[a-z][a-z0-9-]*$`, this will ensure that the field starts with a lower case letter, and then has lower case letters, numbers or hyphens. You can tweak this regular expression as needed to suit your needs. ### Email Validation with Regular Expressions E-mails can be tricky to validate properly, especially because many services _accept_ e-mails that are not valid, and reject e-mail addresses that are technically valid. Additionally, your own capabilities and purposes might inform your decision (e.g., if you support [i18n addresses](https://datatracker.ietf.org/doc/html/rfc6530) or don't then the set of allowed e-mails changes). ### List Validation - `min_length`: Specifies the minimum number of elements that must be in the list. - `max_length`: Specifies the maximum number of elements allowed in the list. The maximum supported value is 1000. - `allowed_type`: Specifies the primitive type that all elements in the list must be. Valid values are `string`, `integer`, `boolean`, `float`, or `any`. The default is `any`, which allows mixed types. This value cannot be changed after the field is created. sample list validation object: ```json { "validation": { "list": { "min_length": 1, "max_length": 100, "allowed_type": "string" } } } ``` ### Any Validation The `any` field type allows storing arbitrary JSON values including objects, arrays, strings, numbers, booleans, and null. When updating an entry, the `any` field value is completely replaced, not merged. Filtering is not supported on `any` fields. sample any validation object: ```json { "validation": { "any": { "allow_null_values": true, "immutable": false } } } ``` ### Null Values All Custom Fields can be configured to restrict the storage of `null` values for that field on a Custom API Entry. By default, this is `true`. sample validation object : ```json { "validation": { "boolean": { "allow_null_values": false, "immutable": false } } } ``` ### Immutable When [creating](/docs/api/commerce-extensions/create-a-custom-field#request) a Custom Field, it can be configured to be `immutable`. When set to true, the value of this field can be specified only during POST requests and cannot be modified during PUT requests. By default, this is `false`. sample validation object : ```json { "validation": { "boolean": { "immutable": false } } } ``` ## Presentation When [creating](/docs/api/commerce-extensions/create-a-custom-field#request) or [updating](/docs/api/commerce-extensions/update-a-custom-field#request) a Custom Field, `presentation` can be used to influence the layout and order of fields within Commerce Manager. It does not affect the order of keys within JSON, nor influence any behaviour outside of Commerce Manager. ## Reserved Slugs The following values cannot be used as a `slug` in a Custom Field. - slug - type - id - meta - created_at - updated_at - links - relationships - attributes - attribute - dimension - dimensions - weight - weights