Where do you put your “secret sauce”, your business logic in SharePoint add-ins that are done entirely with JavaScript? How do you send emails? Do you copy the same code, the same business logic over and over again to each add-in?
The answer is: No, I use code behind, C#. I use Web API.

Add-ins example with C#
Web API allows us to build a RESTful web service that can be accessed and consumed from JavaScript. It allows us to keep light-weight JavaScript based web parts and add-ins on SharePoint pages. A SharePoint add-in that consumes a Web API just might be called a hybrid SharePoint add-in with JavaScript “on-premise” in SharePoint and C# in the cloud as active part of the solution.
In addition, Web API is not restricted to an add-in. We can access the same service from different add-ins. The Web API is consumed by a logic layer in each add-in. It solves the exact same task in each add-in. The Web API is a horizontal layer with business logic in our solution.
Why don’t you just build SharePoint provider add-ins?
- Business logic such as sending an email could be built as a Web API even for SharePoint provider add-ins built with C#
- SharePoint provider add-ins require additional infrastructure and hosting. Relatively small and occasional tasks such as sending an email do not justify the additional infrastructure
- The cost of the additional infrastructure does not fit into the free/low cost model many SharePoint add-ins are sold for. SharePoint add-ins are in many cases downloaded to hundreds or thousands of clients. The cost of hosting a free SharePoint add-in should by all means be rather inexpensive.
What do we need to consume the Web API in JavaScript?
- We need a few lines of code to make a request
var url = “http://secretsauce.azurewebsites.net/api/validation/Validate/” + appname;
var request = new SP.WebRequestInfo();
request.set_url(url);
request.set_method(“GET”);
response = SP.WebProxy.invoke(context, request);
context.executeQueryAsync(function onWent(sender, args) {
var responseBody = JSON.parse(response.get_body());
var validation = responseBody.AppValid;
if (validation) {}
2. We have to add the Web API URL as remote endpoint
How to build a Web API?
Despite ASP.Net Core 1.0 (formerly ASP.NET 5) is yet to be released, there are many fine tutorials about how to build a Web API. Here is a walkthrough of what I did to make it work.
- In Visual Studio 2015, select “Cloud” and “ASP.NET Web Application”

Visual Studio 2015 –> Cloud –> ASP.NET Web Application
2. Then select “Web API”, ASP.NET Core 1.0 (Formerly ASP.NET 5) Template

Select Web API
3. I’ve built a very simple logic. I’ve built app business logic (AppBL) model:
public class AppBL
{
public string AppName { get; set; }
public bool AppValid { get; set; }
}
4. And I’ve built interface repository and repository and “validate” function:
public AppBL Validate(string appName)
{
AppBL item = new AppBL();
item.AppName = appName;
{
case “Carousel”:
item.AppValid = true;
break;
case “SimpleNewsLite”:
item.AppValid = true;
break;
}
return item;
}
5. I also added a controller and defined a HttpGET function:
[HttpGet(“validate/{appName}”)]
public IActionResult validate(string appName)
{
var item = Apps.Validate(appName);
return new ObjectResult(item);
}
[FromServices]
public IBLRepository Apps { get; set; }
6. In the startup.cs, I enabled cross-domain:
services.AddCors(options =>
options.AddPolicy(“AllowAll”, p => p.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader()));
About the Author:
Sonja Madsen has a master degree in Information Science and Multimedia and has worked as a Developer and Architect on many SharePoint projects for the past 11 years. Sonja is SharePoint MVP and owner of SONJASAPPS, SharePoint apps at Office Store.
Follow Sonja on Twitter: https://twitter.com/sonjamadsen