To meet the needs of a wide range of users, a CTI API must support a broad range of applications. These include both "telephony-centric" applications, which have the management of telephone calls as their primary focus (from the simplest dialer or data communications application to complex call center management applications), and "telephony-enabled" applications—those which allow access to telephony features but do not have telephony as their primary focus. Examples of a "telephony-enabled" application would be a personal information manager or database management toolkit with rudimentary ability to place and track calls, most likely by leveraging the user's preferred telephony-centric ("call manager") application.
Some CTI architectures are focused on one facet of the problem, such as call centers (automatic call distribution, predictive dialing, and so on) or ISDN calls from personal computers. Widespread success of CTI requires a broad range of commercial applications—and those applications will never be produced unless developers are convinced that drivers will be available for a wide range of underlying hardware. If the only drivers available are for large PBXs with ACD and predictive dialing features, or for specific ISDN interface boards, major software developers will be reluctant to make the investment to produce applications for that API.
The Windows Telephony API focuses on the "desktop"—generally, a single PC and telephone, however, the capability of performing "third-party" call control (on behalf of other desktops) is preserved where needed. The desktop is assumed, in the parameter structure of API functions, to be one endpoint of each call, thereby simplifying the API and making it easier for programmers to learn and use. The underlying protocol used to control the telephone network or PBX can be either first-party or third-party.