What is an API?
An API (Application Programming Interface) is a set of functions designed for interoperability between two distinct pieces of software.

Web APIs operate as a means of communication via HTTP typically in standard formats (JSON or XML). The implementation is most obvious on Insight and the Opportunity Pipeline views. These pages send and receive all data through the Act! Premium Web API (referred to a ‘the API’ for the rest of this document). 

The API is a standardized interface which can be used by other applications, integrations, plugins, third-party components, and within Act! for additional functionality not present through the SDK.

It is documented in the act.web.api web page (in Act! Premium for Web installs). This page explains the endpoints, structures, and examples on all publicly
available features in the API as well as filters (OData) which can be applied to queries.

The API provides a standardized format to all UI components in the same way. All platforms support web browsers; by using a display mechanism and data source which can be utilized by the same set of controls, subsystems, and codebase across all platforms, the functionality can be better ensured across all systems.
The Insight, Companion (mobile app), Pipeline, and Act! Marketing Automation (AMA) views are web browser controls that load a specific website with certain
parameters. These parameters come from the API.

Act! Premium or Act! Premium for Web (APFW)
For single users or small offices with small databases and very little API traffic, Act! Premium (“the application”) would be a good choice. It incurs little operational overhead and is very simple to deploy

For active subscribers, we provide Act! Connect Link which can provide an externally accessible endpoint for the API so AMA and mobile app can be used in conjunction with on-premise software. As the requirements for larger teams grow, database and API performance requirements will naturally increase.

Act! Premium makes use of the Act! Web API Host service which runs on the local machines. This service is used to provide the API endpoints for the various
internal features within the application without needing to install third-party components. It is important to note that this does not provide a way for AMA, the mobile app, or Contact Link to communicate to the database unless Act! Connect Link is installed. If the computer has Windows Internet Information Services (IIS) or another web hosting system installed and running on port 80, the API will not be able to function.

Act! Premium for Web runs the API inside of IIS. As the technology stack for IIS can deal with larger volumes of traffic and can be set as a direct access point to
the system, performance will be significantly better in this scenario. It is recommended that any externally accessible web servers are provided with a valid
certificate (not self-signed) with unencrypted traffic disabled as a general best practice. The remainder of this document assumes that any web deployment
will have an externally valid server certificate. A valid certificate is required for AMA, Zapier, or Companion. Anyone looking to deploy to larger teams or teams that
will make extensive use of these external components should consider a deployment via APFW: self-hosted, Act! Premium hosting partner, or Act! Premium Cloud.

When is Act! Connect Link needed?

In smaller deployment scenarios when the use of Companion, AMA, or third party web integrations (e.g. Zapier) is desired without the need to run APFW with a
valid certificate, then Act! Connect Link will be sufficient. This scenario should follow the same best practices for the API as outlined below.
Act! Connect Link is not recommended to run with an APFW install. The correct approach for APFW is to have a valid certificate installed on the server.

Why are server certificates necessary?
Server certificates provide the only means by which two computer systems can validate the identity of each other

Within the HTTPS protocol, the client (the machine which is accessing the service) requires the server (the machine providing the service) to provide a certificate. These certificates are issued by a trusted authority (called a Certificate Authority or CA). The certificates which identify the CA are preinstalled in the system in a root certificate store with many being installed by default on Windows.
The only way computers can reliably identify each other is via cryptographic signature. These certificates provide a chain of trust between one machine and another.

General API best practices
When integrating multiple systems, data integrity is vital; this is no different when using the API. In order to maintain data integrity, only one system should be used as a system-of-record

In the case of Act! Premium, this should be the ‘publisher’ database. This minimizes the chance of database collisions and prevents different integrations
from modifying records in two different ways. Remote databases do have their own API endpoint for Insight, KPI, and Pipeline views, but this is working directly on the
database. External records should always go to or from the primary database.
It is recommended that hosting partners or large self-hosted customers running APFW (>25 users) run multiple app  pools and virtual directories for any logical groups (e.g. each customer for hosting partners, divisions with different databases for self-hosted customers). Additionally, machine resources should be scaled
according to load. Virtualized servers with solid-state storage are the easiest to manage and should be considered for any large-scale deployments. Using APFW
with a valid server certificate will be significantly faster than using Act! Connect Link

Deployment Scenarios - Act! Premium

Single-user/single computer
By far the least complex deployment scenario.

1. Install Act! Premium
2. Install Act! Connect Link
3. Open AMA

Shared database multi-computer

1. Install Act! Premium
2. Install Act! Connect Link on the publisher database computer ONLY.
3. Open AMA on the publisher database.

Remote databases

1. Install Act! Premium on all endpoints
2. Install Act! Connect Link on the publisher database computer ONLY
3. Open AMA on the publisher database.
4. Create remote databases.
5. Do not modify the machine name in Network Sync

Deployment Scenarios - Act! Premium for Web

Multi-tentant hosted environments

1. Per-customer app pools and virtual directories for APFW and act.web.api.
2. All remote databases should be on update 5 (or latest available)
3. APCAPIURL and Upward_API_Streamer (HTTPS) should be set in the <database>.dbo.tbl_preference
4. Do not modify the machine name in Network Sync

Self-Hosted private environments (externally accessible over HTTPS)

1. In APFW, access via the externally accessible URL (https only)
2. For the Windows client, create a value for “Upward_API_Streamer” in the act.exe.config 

Self-Hosted private environments (not externally accessible over HTTPS)

1. Install Act! Connect Link
2. Log into Act! and open AMA.

Act! Premium Cloud

1. Ensure all remote databases have update 5 (or latest)

Troubleshooting

These are the most common error pages:

1. Invalid JWT: This is caused when the AMA view is unable to get a token from the URL resolved to from the view
   manager. Technical information about this flow can be found below.
2. Non-provisioned view (no account page):
   Cause 1: This page will be redirected to when the serial number cannot be linked to a customer account at the
   server URL specified. This may occur when the account is purchased by one regional office and is being used by
   another regional office.
   Example: A branch office located in Europe with a UK installation of Act! is using the same AMA and Act! subscription
   serial purchased through US channels. The application config can be overridden to point to the correct server.
   
   Cause 2: An error occurred during the provisioning of the account. Please report this to the sales team

Troubleshooting steps:

1. Ensure all remote clients are running update 5 or later.
2. Any remote clients should not have Act! Connect Link installed.
3. Remove any ‘Upward_API_Streamer’ or ‘Upward_API_Streamer <sync*’ values in the publisher database either with SQL Management Studio or a batch file.
4. Open AMA from the Publisher database.
5. This should set the Upward_API_Streamer value to the correct one.
6. The machine name inside of ‘Tools > Synchronization Panel> Manage Connection Information > Network (inside a firewall)’ contains the actual machine name of the publisher database.
   
   Important!
   If a remote client is still on update 4 or earlier, they will sync incorrect values back up the server and break the AMA view for all users! Update the clients and sync them before you update the values.
   Note: If you are seeing the offline page, make sure the computer can ping “google.com”

Related Articles:

• Understanding how the Act! Web API Works
• Act! Web API Documentation
• What is the Act! Web API?
• Keystroke - Connections
• Act! - Connections