StrikeIron Blog

Validating Email Addresses using REST - an Example

Validating an email address on-the-fly or programmatically can be very useful. For example, you can filter out bogus leads from Web forms before they are ever entered into a prospect database, therefore preventing anyone from wasting time on them. You can also use it as part of a fraud prevention scorecard, or use it scan email addresses iteratively within CRM systems such as Salesforce.com, noting which contacts have email addresses that are no longer valid (likely meaning that the individual is no longer at the company, and perhaps triggering a reason to reconnect with that company).

An easy way to take advantage of email verification is using REST (REpresentational State Transfer). If you are not familiar with REST, it is an Internet protocol used by Web developers that takes advantage of the core architecture of the Web. It consists of "servers" and "clients" either of which can be anywhere in the connected world, with clients making XML requests to a server and the server responding with an answer, also in XML. This is the same way browsers request Web pages from Web sites, although HTML is passed back and forth rather than XML.

In the case of REST, the client is either your browser or an application (can be a SAAS application, traditional software application, business process, or a mobile application such as an iPhone app), and the server is StrikeIron's data center and platform. In this example, the client will be a Web browser, and the server will be StrikeIron's primary data center in North Carolina.

In other words, an automated request containing an email address is sent to StrikeIron's servers, and then upon receipt of the request over the Web, the StrikeIron "service" does some processing and checking, and then returns a response as to whether or not it is indeed a valid email address. This is an alternative to the SOAP Web services protocol that is often used to call these services.

Here is the textual structure for making a REST call using StrikeIron's email verification service that is easy to try:

http://ws.strikeiron.com/StrikeIron/EmailVerify5/EmailVerification/VerifyEmail?LicenseInfo.RegisteredUser.UserID=[UserID]&LicenseInfo.RegisteredUser.Password=[Password]&VerifyEmail.Email=[EmailAddress]&VerifyEmail.Timeout=[TimeoutValue]

In the above example, all parameters required to call the "Verify Email" operation are passed in via the query string in the link above.  You will need to replace each of these tokens (noted by square [] brackets) with the appropriate parameter value.  You will also need to ensure that the values have all URL reserve characters correctly escaped if necessary.

The "Timeout" value in the above string must be an integer value between 30 and 120 and indicates the number of seconds that must elapse before a timeout occurs. This is required because some email servers can take awhile to respond to various SMTP requests, and you don't want to hold up whatever processing you are doing for an indefinite period of time.

If you don't have a StrikeIron UserID and Password, you can register at our site and receive 25 "hits" (executions) for free, and these will be provisioned the first time you execute the service (you don't have to set up the service in advance with your registered account - provisioning is automatic upon execution).

You can also (and should) replace "http" with "https" for a secure invocation of the service.

To try it and experience a REST call, simply copy the above REST text string into any browser URL window (Firefox, Internet Explorer, etc.) like you would any URL address (make sure you replace the values in the [parameter] slots and without the brackets), and you will get the XML response from StrikeIron's servers. That's all there is to it. Of course, if you do this within an application, you will have to parse the results from the XML.

Also, any of the StrikeIron Web services can be called using REST, not just email validation. For example, here is the REST string required to call our SMS alerts and notification text messaging service, enabling text messages to be sent to a cell phone/mobile device (supports over 400 carriers in 160 countries):

http://ws.strikeiron.com/StrikeIron/SMSAlerts4/GlobalSMSPro/SendMessage?LicenseInfo.RegisteredUser.UserID=[UserID]&LicenseInfo.RegisteredUser.Password=[Password]&SendMessage.ToNumber=[ToNumber]&SendMessage.FromName=[FromName]&SendMessage.MessageText=[Message]

Once you've mastered the ability to make REST calls within Web applications, or any other application where it is appropriate, you can really build some incredible functionality that leverages the architecture of the Web, cobbling together some of the best the Web has to offer.

Twenty-Five Use Cases for SMS Text Messaging Alerts and Notifications

This past Fall, the CTIA wireless industry organization reported that over four billion text messages were being sent PER DAY over U.S. carrier networks, doubling the number from just twelve months earlier. Clearly, text messaging is still growing at an explosive rate and finding its way into more and more business applications.

StrikeIron has been offering the capability to send an SMS message via a programmatic interface for quite some time now, enabling text messages to be sent to mobile devices from a software application based on business some defined automated trigger. Also, its global capabilities have provided us with a diverse, worldwide customer base that puts this service to use.

Making a SOAP or REST call to our SMS Alerts and Notifications API is an easy, cost-effective way to integrate text messaging into a wide array of business processes. Supporting 400 carriers in 160 countries, much of the traditional complexity for SMS-enabling applications disappears with this Web service.

Here are twenty-five use cases I've compiled to demonstrate some of the ways text messaging can be put to use. This should help people think creatively about ways to utilize text messaging to match their own scenarios:

- Doctor/dental Appointment reminders

- Let people know of time-sensitive events, such as school closings

- Send broadcast communications to employees out in the field

- User/identity verification (sending out a code via SMS to then enter into a Web site to confirm physical ownership of the mobile device)

- Send immediate, weather-related offers to opted-in customers, such as at a ski resort when a large amount of snow falls

- After online purchases, let a customer know that their product has been shipped and should be received shortly (reduces calls to customer support)

- Send scheduled reminders to customers, such as when its time to replace eyeglasses

- Alert support representatives when someone in their geographic region is having a technical issue so they can respond quickly

- Alert IT operations and engineering staff on warnings and issues occurring in 24x7 production system environments

- Hospitals/doctors alerting patients when test results are ready

- Let patrons know their table is ready at a restaurant, allowing them to move beyond very short distances

- Remind customers that scheduled automobile service is due

- Allow efficient, repeat ordering of a product with previously used order details

- Use SMS voucher campaigns, where recipients provide a code received via SMS to take advantage of an offer

- Some radio stations are accepting SMS messages and responding with what song is currently playing on the radio (reduces number of people calling the station)

- Giving donors real-time updates as to how their donations are being spent

- Let customers of car/driver services know exactly where their driver is waiting

- Real-time notification of real estate pricing changes on previously inquired-about properties

- Word-of-the-day, quote-of-the-day, and other *-of-the-day services for brand building

- School truancy prevention (letting parents know via automatic text alert when their children are absent)

- Politicians communicating important issues with their constituency, including fund-raising events

- Notification of unusual account activity to help reduce/prevent fraud

- Self-scheduled alarms/reminders (such as birthdays)

- Using SMS to communicate with and disable laptops (that have been stolen, for example), delete sensitive data, or other security measures (some software applications enable this now)

- Notifying customers of important service changes (delayed flights for example)


And of course, there are multiple variations of each of the above use cases. While some of these are not new use cases, they collectively make the case that SMS text messaging enables all sorts of new opportunities for those who put it to use, and helps explain the dramatic rise of messages that the carriers are reporting.

Similarly, if you want to extend notification capabilities beyond mobile devices or add voice capabilities, StrikeIron also offers a text-to-voice (or mp3/wav files) API Web service that enables delivery of voice notifications and alerts via any phone (land line/VOIP) via a computerized voice, not just mobile phones such as text messaging is limited to.

Brokering Data via Web Services for CRM, Marketing, and E-Commerce Applications

StrikeIron has been brokering data to a large number of customers in production applications for quite some time now. We launched our "Web Services Marketplace" in 2005, but had customers commercially consuming data from us from within their applications and Web sites as early as 2004.

During this time, we've learned a great deal about serving up data over the Web to many different kinds of systems, including increasing levels of performance, methods of redundancy and fail-over, customer usage patterns, service normalization, and more. We now have thousands of production applications depending on immediate, real-time data delivery from our platform and its underlying data center. All we have learned over time has been applied, enabling us to incrementally improve the software and hardware infrastructure that serves at the core of our delivery platform that makes our business possible. This Web-based technology is what we effectively timeshare to our customers as they consume data and other SOAP and REST based API services from us.

Three application areas where this solution, our platform, and our universe of data sources have really resonated since the beginning is CRM, Marketing applications, and eCommerce, three areas of course that are fairly related. These applications stand to gain considerably from this type of capability primarily because these are disciplines that rely heavily on data and the accuracy and completeness of it for success.

CRM applications make use of real-time data to validate and enrich addresses, phone numbers, and email addresses, all vital data components that must be both present and accurate for effective CRM. This is an important application segment for us with lots of customers using us across many diverse CRM applications and software/hardware configurations. We have even done a native Force.com integration with the Salesforce.com CRM platform, so these data sources can be utilized by Salesforce.com users quickly and easily.

Many of our customers are marketing firms working with their clients' data to improve the quality and accuracy of a marketing database, fill in the missing data points, and expand the amount of per-contact data available for more effective marketing campaigns. So much of the success of these campaigns are dependent upon the data that drives them, and hence the integrations with StrikeIron and our real-time data feeds and data verification capabilities.

We also get a large number of customers using us in e-commerce scenarios, where a single online transaction might consist of calls to our sales tax rate data sources for sales tax rate compliance, address verification for purposes of shipping accuracy, foreign exchange rates for localized pricing and/or aggregated reporting, SMS or text-to-voice IVR services for shipment notification, and perhaps one or more of our demographic services to help with customer profiling and segmentation.

To provide the necessary data content through our platform to fuel these applications, we've brokered relationships with a diverse set of data providers and performed a series of normalization steps to reduce complexity for the user/developer/integrator. We provide this data in easy-to-integrate Web service API form, each data product with the same business model, for significantly reduced complexity for the customer.

One of the key reasons our customers subscribe to services from us is because we handle all of the ongoing data updates and maintenance so they don't have to. It's automatic. That way, they can maintain their focus, creativity, and efforts around their CRM, marketing, and e-commerce applications. And if you know how to make use of one of our data sources, you know how to make use of all of them as they all work in the same way, with the same interfaces, the same sets of behavior and responses, and the same business model.

So far, this has been a successful model and approach to the market. Of course, we have hundreds if not thousands of use cases that extend beyond these three types of applications, as any type of application can benefit from real-time access to various data sources. But these three seem to represent the sweet spot for real-time, XML-based Web services APIs.

The Business Case for Ongoing Data Quality via the Web

The Quality of data stored within an organization's various databases is an important business issue. Customer and operational data is used often at a high level as the basis for strategic decision making. It also used simply for operating a company on a day-to-day basis, guiding activities and triggering business processes to occur. Obviously, poor data quality at an organization's core can cause a great deal of harm both at a strategic level as well as at an operational one.

As a simple example, suppose the average customer for a bank represents about $3,000 per year in revenue for that bank (largely from fees and interest payments). Over a five year period, simple math demonstrates this same single customer represents $15,000 in revenue. In other words, in the financial services industry, there is a high dollar amount of value on a per customer basis.

If data about an individual customer is incorrect, not updated, or otherwise insufficient, it could then result in poor customer service, especially from the perspective of the customer. The customer might have updated his or her information at a branch, or online (or so they thought), but for some reason, the update never occurred in the master customer data file. Or perhaps the data was collected incorrectly, causing important communication from the bank to the customer to subsequently be missed. This could anger the customer who then leaves to go to a competitor, along with his or her $15k five-year value. This is bad news. In fact, almost any business function within a company can suffer from poor data quality.

Conversely, good business intelligence based on sound quality data can help target potential new customers with timely, relevant offers and also solidify relationships with existing ones by predicting the various financial services products they are likely to need at any given time.

Clearly, these numbers can add up quickly for financial institutions with thousands, hundreds of thousands, or even millions of customers. This customer value number may be larger or smaller in other industries, but it is rare that it is not significant. In other words, the quality of a corporation's data assets can be critical to business success.

So what can be done?

Many organizations practice one-time mass data cleansing efforts. However, the day after this effort is completed, data quality can begin to erode again as new data is collected from various points both external and internal to the organization. Since one-time cleansing efforts are rarely cheap and without major effort, it is wise to engage in an ongoing data cleansing effort.

Integrating data cleansing into business processes can greatly reduce systemic data quality issues, decreasing the need for these large scale one-time data cleansing efforts. Data is collected through many different points within a company, including via Web forms, customer service representatives, written communication, and more. Information should be verified, corrected, and enhanced where possible (with additional data fields) before it ever gets into corporate databases. Once an emphasis on a high level quality of data has been championed across the organization, this can be achieved at a tactical and technical level by introducing data quality checks at these various data collection points.

The cost of doing this can be dramatically decreased by performing these data verification checks using constantly-updated data sources and data verification functions that exist out on the Web, or in the "cloud" (some will debate if there is even a difference). A simple example is every time a telephone number, email address, or physical address is obtained, whether over the phone, in the mail, or via a Website, a simple cloud-based check via a verification Web service API can be performed to ensure the validity of the information that is received. The verified data can then be enhanced with other data points that are strategic to the organization, such as the number of employees that exist within a customer's company, a number that might be significant to various business processes.

Using data-as-a-service capabilities like these will go a long way in helping your organization achieve data-as-an-asset rather than data-as-a-liability, and directly affect the bottom line to a substantial degree by significantly reducing the need for cyclical mass data cleansing efforts.

A Consistent Business Model Across Many Different Web Services

One of the things I always like to point out is the advantage of having a consistent business model across many different SOAP and REST-based Web services and Web-based APIs when integrating external functionality or data into an application, Web site, or business process from the cloud.

For example, one area where StrikeIron makes many different useful Web services available is in the area of e-commerce. These services include things like United States, Canada, and even a broader global address verification and correction capability that is easy to integrate into any Web form where customers and potential customers' addresses are collected.

Also, we provide sales tax rate services, foreign currency exchange rate services (for showing local pricing), telephone number verification and lookup services, business demographic services (for customer profiling) and even services such as SMS text messaging and IVR text-to-voice for several different purposes, including shipment notification, as part of an e-commerce transaction.

We have found success because many organizations would rather outsource the ongoing data management and data updating process of these services rather than undertake the cost and complexity of doing it themselves. This is the ideal data-as-a-service model.

Rather than building out more non-core IT processes, an organization can then focus its efforts on its primary business and specific business processes related to it. This approach also ensures that all data sources are as current as possible, and a lot of functionality and detail is abstracted from the development group.

All of these various services combine for the occurrence of an optimized, enhanced, and substantially less complex e-commerce transaction with significantly less IT resources (and cost) required.

Now, the key point: one major advantage of incorporating multiple services like this through StrikeIron is that in each case, the business model behind the usage of these services is the same. This makes it dramatically easier to incorporate these services into an e-commerce Web site because you don't have to worry about business model differences from service to service, and adhering to many different business models dreamed up by many different vendors.

Otherwise, if functionally is cobbled together from many different sources, code will have to be written on a per-service basis to account for the different business models that might exist from each vendor, and this in turn introduces a good deal of complexity into an e-commerce site. In some scenarios the grim details of these differences will not arise until periods of heavy usage occur and you find yourself in a scenario dealing with several different vendors and their business models, a potentially stressful scenario indeed.

A few examples of simple variations of these Web service and Web API business models found across the Internet include monthly subscriptions, annual subscriptions, per-transaction fees, daily usage limits, ip-address level fees, developer key usage allotments, "credits" used in multiple ways, flat rates plus additional usage, and several more.

Providing business logic for adhering to multiple business models such as these and their various contingencies as part of business processes can be a tall order, and some of the simplicity sought in this model in the first place is then canceled out.

This is why we think our approach is simplest: many services and capabilities + one business model = dramatically less complexity. As people build more and more of the cloud into applications and Web sites, I think you will see this approach, which is practically a form of cloud business middleware, emerge.

Of course, it is true that you have more reliance on a single vendor in this scenario, and depending on the vendor this can be both good and bad. Now of course no one is 100% perfect, but I definitely have faith in our engineering and customer support teams, and we have a long list of customer references that will attest to the strength of our offerings and the system we have built and improved over the years. However, certainly do your due diligence on any vendor in any scenario when considering a consolidated approach such as this.