Dev GuideAPI ReferenceUser Guide
Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback

To help you plan for and build Optimizely <<product-name>> extensions that will work with the Mobile App both now and/or in the future, consider the following scenarios when approaching development.

Optimizely recommends adding custom business logic on the API and/or server-side first. Assess the impact of these customizations to ensure they work well on both your <<product-name>> website and the Mobile App before exploring other ways of extending the system or business logic.

Want more information about the <<product-name>> Mobile App and the functionality it includes? Read more here: [What is the <<product-name>> Mobile App?](🔗)

## Scenario - Custom field required to submit orders

You add a custom field to the <<product-name>> storefront and want to require it to have a value before customers can submit orders. You change the relevant API endpoint to accommodate for and require the new field.

**Considerations**

While we don't prevent you from adding custom fields to an API, consider:

  • <<product-name>> websites and the Mobile App have separate user interfaces, so anything you customize (including adding fields) on the storefront does not cascade to the Mobile App that is Themes, JavaScript, CSS, and so on.

  • Making custom fields required via the API will block orders submitted through the Mobile App

  • Explore alternatives like adding the custom field to a modal window at a different point instead of at order submission

## Scenario - Product availability messages

<<product-name>> passes a product availability message to your customers as a string of data through an API. You want to format this message so it is easier for your customers to read. You put logic on the storefront side to insert pipes to parse the message when it displays to customers.

**Considerations**

While using pipes in the storefront logic to parse the data string doesn't break anything, consider:

  • <<product-name>> websites and the Mobile App have separate user interfaces, so anything you customize (including formatting data strings) on the storefront does not cascade to the Mobile App that is Themes, JavaScript, CSS, and so on.

  • The Mobile App will continue to use the data string and display the product availability message as-is to your customers

  • Explore alternatives like adding logic to the relevant API if you want to expose additional values for use on both your <<product-name>> website and Mobile App