Ask a Dev

From Russell: Calling custom-created Extension functions from Retail and Web Office can be tricky, but it's not bad when you know what's happening. This interaction I think will help clear things up, and I've added a couple of notes below.  Please note that there are two proxy pathways used in the Retail/Web Office API space, "Proxy" (for logged-in users), and "AnonymousProxy" (for anonymous users). The "AnonymousProxy" you were calling required a status code of "0" (worked with non-Extension API calls from our previous Client DLL). There's a new one we added recently that allows you to call Extension APIs without requiring weird data structures. (the only difference is calling the "AnonymousProxySimple"). var request = {   Region: "us", }; var baseUrl =   "/AnonymousProxySimple/demo/get-enrollment-activation-kits?timeout=30000"; // "demo" is the client ID. Put yours here. $RestService   .V3Post(baseUrl, request, true, true)   .then(function (result) {     var response = JSON.parse(result.data.ResponseBody);     console.log(response); })   .catch(function (err) {     console.log(err); }); **Note to widget developers**: This same rule applies in the Back Office code. "ProxySimple" and "Proxy" behave differently. You can get rid of that "Status" ID and any other structures and just work directly with results if you use "Simple" **There are extensive notes on the topic. This is from a document in the DS internal help site**:   # Authenticated Customers There are two proxy endpoints that authenticated customer accounts can use: Simple and Standard. These are called by custom content pages and widgets in the back office and retail site. ### Simple Endpoint The simple endpoint is recommended over the standard endpoint because the requirements are less stringent for the Disco client API that is called. Let's walk through what happens when a call is made to the simple endpoint. 1. Suppose the following is posted to the simple API endpoint: Request URL: https://api.directscale.com/ProxySimple/Associates/GetEyeColor Request Body: { associateId: 4567 } Notes: A request to the proxy endpoint must be a POST. Even if you are not sending a request body to the proxy endpoint, you must still use a POST. The authentication token of the logged in customer account is required in the request header in the same manner as all other customer API endpoints. 2. The API proxy sends the following request to Disco: Request URL: https://{clientname}.corpadmin.directscale.com/Command/ClientAPI/Associates/GetEyeColor Request Body: { associateId: 4567, authenticatedAssociateId: 1234 } Notes: The proxy API will determine the correct clientname to use on the domain of the request to Disco by looking at the passed user auth token. It has embedded in it the client the user belongs to. You should not pass an authenticatedAssociateId parameter on the post to the proxy. The proxy will add the authenticatedAssociateId parameter when it prepares to call Disco. If a call to the proxy includes this parameter, it will be overwritten by the API proxy with the logged in user Id. If a Disco API does not need this parameter, it is ignored. All Disco custom client API endpoints begin with the root level path /Command/ClientAPI. This is automatically prepended to the passed path from the proxy call. So, do not add /Command/ClientAPI to your proxy call or it will be sent to Disco as /Command/ClientAPI/Command/ClientAPI. Note on Timeout: By default, the request to Disco will timeout after 10 seconds. If you need to adjust that timeout, an optional timeout query parameter timeout may be passed on the call to the proxy. The value is the number of seconds to use for the request timeout on the call to Disco. 3. Disco returns some kind of message back to the proxy like this: Response Status Code: 200 Response Body: { Color: 'Green' } Notes: Custom client Disco API endpoints should make use of the authenticatedAssociateId parameter when they need the logged in user Id. In the case of the example above, the Disco API should check that the associateId passed is in the downline of the authenticatedAssociateId or perform whatever other security checks are prudent for the endpoint.  4. The proxy returns the data from Disco like this: Response Body: { ResponseBody: { Color : 'Green' }, ResponseStatus: 200 } Notes: The ResponseStatus is set to whatever HTTP response status code the call to the Disco endpoint returned. The ResponseBody is set to whatever response body the Disco endpoint returned. If the call to the Disco API timed out or had a TCP error, the proxy will return a 500 HTTP response with an empty response body. The Intranet logs time outs and TCP errors on the Exception Logs page. ### Standard Endpoint The standard endpoint is the first version of the proxy. It expects Disco endpoint responses in a certain format. Let's walk through what happens when a call is made to the standard endpoint. Notes from the simple endpoint apply here too except where otherwise noted. 1. Suppose the following is posted to the standard API endpoint: Request URL: https://api.directscale.com/Proxy/Associates/GetEyeColor Request Body: {associateId: 4567 } 2. The API proxy sends the following request to Disco: Request URL: https://{clientname}.corpadmin.directscale.com/Command/ClientAPI/Associates/GetEyeColor Request Body: { associateId: 4567, authenticatedAssociateId: 1234 } 3. Disco returns some kind of message back to the proxy like this: Response Status Code: 200 Response Body: { Status: 0, Message: null, Data: { Color: 'Green' } } Notes: The API proxy is expecting that the Disco endpoint will return a JSON object in the response body with the properties Status, Data and Message. 4. The proxy returns the data from Disco like this: Response Body: { ErrorMessage: null, Response: { Color: 'Green' } } Notes: The response JSON object of the API1 proxy includes two properties: ErrorMessage and Response. ErrorMessage contains the value of the Message property returned in the Disco response when the Status property is set to a non-zero value. Otherwise it will be null. Response contains the value of the Data property returned in the Disco response when the Status property is set to zero. Otherwise it will be null. If the Disco call returned a non-zero value of Status, the Intranet will log the error and the proxy will return an empty 500 HTTP response in the same manner as the simple endpoint error handling. # Unauthenticated Customers The unauthenticated proxy endpoints are called by enrollment or other sites that do not have a logged in user auth token to pass. The endpoints behave in the same manner as the authenticated customer endpoints except: No authenticatedAssociateId parameter is added to the requests to Disco because the user is not logged in. The paths of the endpoints require the name of the client be passed. Simple Endpoint: https://api.directscale.com/AnoymousProxySimple/{client}/{the rest of the path} Standard Endpoint: https://api.directscale.com/AnonymousProxy/{client}/{the rest of the path} # Authenticated Admin Users There is only one authenticated admin user proxy endpoint. It is called by custom content admin pages. The admin proxy endpoint behaves in the same manner as the authenticated customer simple endpoint except: The authenticatedAssociateId that is passed to Disco by the proxy is, of course, the Id of the logged in admin user not the Id of a logged in customer. The path of the admin endpoint is: https://api.directscale.com/Admin/Proxy/{the rest of the path} Read more: [Client API Proxy: Corporate Office (Disco)](https://developers.directscale.com/docs/disco-client-api-proxy)

From Russell: **Q**: Do we need to call `SaveCoupon` from `couponService` or not while creating a custom coupon and applying it on the order on the fly? Also, does adding a newly created coupon mean that only its couponCode should be added to the `string[]` of the `orderCoupons` object? **A**: When using the **ProcessCouponHook**. You have two options: 1. Add an existing coupon code to the `string[] CouponCodes`, then call the base functionality `func(request)`. If you use this method, the coupon code has already been set up in the system and will determine its discount amount. You are just adding to the order automatically. 2. Build your own Discount. Sometimes you want to build a discount that is different for everyone. In this case, you will run the base functionality and develop your `OrderCoupon` object. Using this method, you can create the discount amount very custom per person and order. This object asks for a `couponID`, which is looking at coupons that already exist, but you do not have to give a valid `couponID` if you don't want to. If you give it a valid `couponID,` the only thing that it will do is show that a coupon was used on this order in the UI.

**Q:** We have a Family & Friends Associate Status and we want to auto apply a coupon for any autoship orders so they receive a discount, how can we do that? **A:** Because DirectScale does not have a UI to attach a coupon to an autoship, a hook must be used to auto apply the coupon. ### **Hook To Be Used** ***Orders.ProcessCouponCodes*** In Orders.ProcessCouponCodes Hook look for **OrderType=2** and **AssociateStatus=(*The ID of this AssociateStatus*)** Automatically apply coupon code **[ENTER COUPON CODE HERE]** to the order.

From Russell: Sometimes, it's essential to know whether you're running in a Sandbox or the Live environment and to verify the Client ID of the instance you're running on. This can be done in the extension using the following: ExtensionContext is part of the SettingsService (ISettingsService), which can be injected. Once you've got the handle to SettingsService, do this: ``` string clientId = _settingsService.ExtensionContext().ClientId; // IE, "demo" DirectScale.Disco.Extension.EnvironmentType envType = _settingsService.ExtensionContext().EnvironmentType; // EnvironmentType is an enum, and can be either Sandbox or Live ``` Read more: [Verifying Extension Environment and Client ID](https://developers.directscale.com/docs/verifying-extension-environment-and-client-id)

Monthly service fees have been getting created as Standard Autoships. They want to update them them to **”Renewal”** autoships so that the users can not see or cancel them from their Web Office Manage Autoships section. # Work to be done: - Write a query to find all current autoships that have ItemID (enter ID of subscription SKU) and no other items on the autoship - Send the List to Client to verify and have as a backup -Once Approved, update the same list to change the autoship type from **”Standard”** to **”Renewal”** -Write a query to find all autoships that have ItemID (ID of Subscription) plus any other items - Send List to client so they can update these Manually - Client will break out the autoships and update the monthly subscription autoship to type **”Renewal”** **Note:** Update the Service type in CRM_ServiceItems in the Data Editor so all future enrollments will have their monthly subscription created as a Renewal Autoship. See This help guide for more information on [Subscriptions](https://help.directscale.com/hc/en-us/articles/360053001273-Subscriptions-Services-Guide)

**Problem:** Client has a separate business entity that will be collecting the fees for the Affiliate Membership Subscription fees. This business entity is not using the same merchant processor as the standard product ordering or Affiliate application process. We have set up a custom store (we re-used the Party store and renamed it) and have put the inventory and merchant information in this store. This project is to implement the back end ties in the Retail Shop to this custom store with a separate checkout flow on a custom page. The Client understands that because the fees to collect the Membership Subscription will be collected by one merchant and the orders placed for product will be collected through a different merchant that the user will have to enter their credit card information and check out twice. **The flow will be as follows:** 1. Home page: 1. User clicks to become an Affiliate through the banner link or clicks on the navigation bar to Join as an Affiliate. 2. Custom Membership Subscription/Checkout page: 1. This page will use storeID:? and automatically add in itemID:? (Client Membership Fee Subscription Monthly) to the cart. 2. After the user successfully enters their information to create their account and pay for their order, they will be created as associate type=1 and the order will be placed 3. Instead of being redirected to the order confirmation page, they will next go to the Application page to complete the rest of the affiliate sign up process. (/Application?type=1) 3. Application page: 1. The application page needs a new section with the order confirmation for the membership subscription fee. 2. The rest of the application will remain designed as it is today but all fields already collected (name, email, address) will be carried over to the application page. 3. NOTE: The CC info will be different so we can not take that info from the membership page to the application page. **Additional Requirements:** The user should not be able to get to the application page as a type=1 user without first going through and successfully purchasing a subscription.

Q: How can I view and update the stock level of an inventory item in Disco via the public API? A: This can be done using a few calls in the "Products" section. You can find the warehouse list via API from the Products/Get Warehouses call. # GET Stock Level call: **Note:** This is the only call that retrieves stock level on an item. You won't find it in the Get Item call. **Note 2:** You will not find Warehouse in the Get Item call. You will need to know the warehouse you're fetching for. For this example, the Warehouse ID is "2". Here I'll grab stock for Item 2, warehouse 2: URL: `https://dsapi-stage.directscale.com/v1/products/item/2/stockLevel/2` Response: ``` { "WarehouseId": 2, "ItemId": 2, "Committed": 0.0, "OnHand": 6000.0, "OnOrder": 0.0, "TrackStock": 1, "Avaliable": 6000.0 } ``` # PUT (Update Stock Level): I looked at the system that the API works with, and I see that it expects this payload: ``` { "Item": { "WarehouseId": 0, "ItemId": 0, "Committed": 0, "OnHand": 0, "OnOrder": 0, "TrackStock": 0, "Avaliable": 0 } } ``` The ItemId needs to be passed in the URL, like this: ``` https://dsapi-stage.directscale.com/v1/products/items/{itemId}/stockLevel ``` It will then be added to the payload for the back-end system. # Example: I will now call the "Update Stock Level" API for item 2: URL: `https://dsapi-stage.directscale.com/v1/products/items/2/stockLevel` PUT Request: ``` { "warehouseId": 2, "onHand": 1234 } ``` HTTP Response: 200 Now we will verify that this actually did something :) GET URL: `https://dsapi-stage.directscale.com/v1/products/item/2/stockLevel/2` Response: ``` { "WarehouseId": 2, "ItemId": 2, "Committed": 0.0, "OnHand": 1234.0, "OnOrder": 0.0, "TrackStock": 1, "Avaliable": 1234.0 } ``` It worked!