Service Objects’ Blog

Thoughts on Data Quality and Contact Validation

Email *

Share

Posts Tagged ‘Tech Support’

Salesforce Trigger Integration – Video Tutorial

Here at Service Objects, we are dedicated to helping our clients integrate our data quality services as quickly as possible. One of the ways we help is educating our clients on the best ways to integrate our services with whatever application they may be using. One such application where our tools are simple to implement is Salesforce.

Salesforce is, among other things, a powerful, extensible and customizable CRM. One of the advantages of Salesforce’s extensibility is that users can set up triggers to make external API calls. This is great for Service Objects’ customers, as it allows APIs calls to any our DOTS web services and helps ensure their contact data in Salesforce is corrected and verified.

In the video below, we will demonstrate how to set up a trigger that will call our DOTS Address Validation 3 service whenever a contact is added to our list of contacts.

See full transcript below.

Hello, and welcome to Service Objects video tutorial series. For today’s tutorial we’ll be setting up a trigger and a class in Salesforce that will call out to our DOTS Address Validation 3 web service. If you don’t already know, Salesforce is an extremely powerful, extensible and customizable CRM. One of the great things that we like about Salesforce here at Service Objects is the ability to call out to APIs so that the data going into your CRM can be validated and verified before it gets entered. This means that you can call out to any of our APIs from Salesforce. You can use this video as an overview for how to integrate any of the service, but for this specific example we’ll be using DOTS Address Validation 3.

To participate in this tutorial, you need the following items. A Service Objects web service key, whether that is a trial key or a production key. You can sign up for a free trial key at www.serviceobjects.com. You will need a developer account in Salesforce. You will also need a working knowledge of Salesforce and Apex, which is the native programming language inside Salesforce. We will go ahead and get started.

To start off, one of the first things we’ll need to do is add the Service Objects endpoint into the list of allowed endpoints that Salesforce is allowed to contact within your developer platform. To do this, you can navigate here and type in remote site settings, or remote, and the remote site settings field will pop up. Here, you’ll see a list of all the websites that your Salesforce platform is allowed to contact. In my account here you can see I have ws.serviceobjects.com and wsbackup.serviceobjects.com. To add a new site, you’ll go and select new remote site. Give an appropriate name, and you will type in the URL here. You can see for this example I’m going to type in trial.serviceobjects.com which will only work if you have a trial license key. If you have a production key, you want to add ws.serviceobjects.com and wsbackup.serviceobjects.com as those will be the two primary URLs that you will be hitting with your production Service Objects account.

This trial.serviceobjects.com URL will only work with trial license keys. Click save and new or just save. You see here if we go back to our remote site settings, you can see that trial.serviceobjects.com was successfully added to our remote site settings. Now that we have successfully added the Service Objects endpoint, we’ll want to add some custom objects in our contact field that will hold some of the values that are returned by our DOTS Address Validation 3 web service. To do that, we’ll scroll down and go to customize. In our example we’re using the contacts field, but you can add custom fields to whatever field is most appropriate for your application, and we’ll select add custom field to contacts. Once we are here, we will scroll down and scroll to this contact custom fields and relationship. You can see here I have several custom fields here already defined. I have a DPV, mostly DPV information and error information, which our field set will parse out from our Address Validation 3 response.

We’ll add another field here for the sake of example. For this field we’re going to add the Is Residential Flag that comes back from the Address Validation 3 service. For this we’ll select text, select next, and here we’re going to go ahead and enter an appropriate field name, which I have in my clipboard. We’re going to call it DotsAddrVal_IsResidential. If you hover over this little “i,” it will say this is the label. This is the label to be used on displays, pages layouts, reports, and list views. This will be a more of a pretty type display. You’ll want to name it something more appropriate and something that will work better in your workflow, but for our example we’re just going to name it this.

For length, we’re going to do length of 15, and for the field name we’re just going to call it AddrValIsResidential. This is the internal field name here. When you’re calling an internal field name, you’ll have to add a double underscore and C in the Apex class. We’ll see an example of that in the next piece of code that we’re going to add. We’ll select next. You’ll select the appropriate field level security here. Next again, and go ahead and click save. To add the actual code that will call out to our Address Validation 3 web service, we’ll scroll down here, go to develop Apex classes. I have already added the class to my developer console, but just for the sake of example, I’ll go ahead and delete it and re-add it. I already have the code in a text editor, so I’m just going to copy and paste that, and just go over the code and explain some key points of it.

Now that I have my code copy and pasted in, I’ll walk through some key elements of it. In the sample code that we have, we have some extra commented out information here that gives you some resources like the product page, the developer guide. You can download this sample code along with this tutorial so you don’t have to pause the video and type it out and everything. The first thing we do is substantiate some of the HTTP request objects in this call WS by ID method. We’ll pull back the contact that’s just been added, and so we’ll pull back all these fields. Mailing street, mailing city, postal code, and state as well as the custom DPV and error information fields that we’ve entered into Salesforce. To call an internal field, an internal custom field that you’ve created in Salesforce, you’ll need to add this double underscore C at the end of it. We can see that we’ve done that here and other place where we reference these objects in the code.

Here, you can see we set the endpoint of the request to the trial URL endpoint, and this will point to the GetBestMatches JSON operation, so this will return a JSON formatted output. We’ve URL encoded all of the address information here. As you can see with this EncodingUtil.urlEncode. We’ll encode it to the UTF-8 standard. Another thing to note here is that you’ll have to put in your license key in this field here. Right now we just have it as a generic WS72 XXX, etc, but you’ll want to put in your specific license key. Here, we’ll send a request to the service, and if the response back is null, then that means there was something wrong with the primary endpoint, so we’ll come back here and check out our backup endpoint. For this example, it’s pointing to the same URL, the same trial endpoint. If you have a production key, you will want to point this primary URL to ws.serviceobjects.com, and this backup URL to ws.backup.serviceobjects.com. You’ll want to be sure to change both the license keys to whatever your license key is.

After that failover configuration, we’ll see here we checked the status code. If it’s equal to 200, we’ll go into processing the response from the service. Create some internal address fields here, and we’ll initialize the error response here to none, which would indicate that no error was returned from the service. What this does is it traverses through the JSON response of the service, and it finds the appropriate field. For this case we’ll see if it finds address1, it will set our initial address field to the address1 that was returned from the service. That will be the standardize and validated address information that is returned. We do that with all the fields that are pertinent to us. The DPV and DPV description, DPV notes description, as well as the IsResidential and error fields down here.

Here, you can see if we get a DPV score equal to 1. That indicates that the address is mailable, it is deliverable, and it is considered good by the USPS. This is the L-statement for the 200 code check here. If the 200 code wasn’t right, then we’ll say put the error description as this generic error message. At the end of this, we’ll update the list of contacts, so we’ll go ahead and click save. Now that we have our TestUtil class made here, we’ll go ahead and scroll down, select Apex triggers. To add a new trigger, we’ll select developer console, select file, new, trigger. For a name, we’ll simply call it Test Trigger.

We’ll go down here and select the contact object. We have the little bit of code right here. I have the actual code in a text editor that will call the service, so I’ll just copy that in. Now that I have this copied, you can see here that whenever a contact is added, or before it’s inserted rather, it will call the class that we made which was called WS by ID, and it will send the contact to it. To save this, just simply go to file and save. Hit refresh. We can see we now have a test trigger here. Now, to add a contact and to test out our new trigger, we’ll simply go up here, select contacts. In recent contacts, you can see here we don’t have any, so let’s go ahead and add one. We’ll add in a fake person by the name of Jane Doe. Go down here to the mailing street information, and we’ll enter in an address. For this example, we’re just going to use our Service Objects office address. We’ll put some typos in there so you can see the standardization and validation that the Service Objects web service does.

We’ll do 27 East Coat. That’s suite number 500. We’ll do Sant Barb for Santa Barbara and CA and 93101. We’ll go ahead and save the contact. You can see here that we still have the old values here, and that’s because the Salesforce doesn’t immediately call the outside APIs. It cues it up a little bit, but if we go and select Jane Doe again, we can see that now we have a standardize address here. In our DPV description, we have a message that indicates, “Yes, this record is a valid mailing address.” For this DPV score, we get a score of one. We can find the “Is Residential,” says false, meaning this is a business address. Again here, we see that the validated address, we see the USPS standardize version of the address which is 27 East Cota Street, Suite 500, as well as the validated city and zip-plus four information.

This concludes our tutorial for how to add a trigger and a class that will call out to our Service Objects web service. If you have any questions or any requests to other tutorials, please feel free to let us know at support@serviceobjects.com. We’ll be happy to accommodate.

 

The Difference Between Customer Experience And User Experience

There are a lot of buzzwords thrown around in the customer sphere, but two of the big ones relate to experiences—customer and user. Although CX and UX are different and unique, they must work together for a company to have success.

User experience deals with customers’ interaction with a product, website, or app. It is measured in things like abandonment rate, error rate, and clicks to completion. Essentially, if a product or technology is difficult to use or navigate, it has a poor user experience.

Customer experience on the other hand focuses on the general experience a customer has with a company. It tends to exist higher in the clouds and can involve a number of interactions. It is measured by net promoter score, customer loyalty, and customer satisfaction.

Both customer experience and user experience are incredibly important and can’t truly exist and thrive without each other. If a website or mobile app has a bad layout and is cumbersome to navigate, it will be difficult for customers to find what they need and can lead to frustration. If customers can’t easily open the mobile app from an email on their phone, they likely won’t purchase your product. Likewise, if the product layout is clunky, customers likely won’t recommend it to a friend no matter how innovative it is. User experience is a huge part of customer experience and needs to play a major role when thinking like a customer.

Although UX and CX are different, they need to work closely together to truly be successful. Customer experience representatives should be working alongside product engineers to make sure everything works together. By taking themselves through the entire customer journey, they can see how each role plays into a customer’s overall satisfaction with the product and the company. The ultimate goal is a website or product that beautifully meshes the required elements of navigation and ease with the extra features that will help the brand stand out with customers.

When thinking about customer experience, user experience definitely shouldn’t be left behind. Make both unique features an essential part of your customer plan to build a brand that customers love all around.

Reprinted with permission from the author. View original post here.

Author Bio: Blake Morgan is a customer experience futurist, author of More Is More, and keynote speaker.

Go farther and create knock your socks-off customer experiences in your organization by enrolling in her new Customer Experience School.

DOTS Address Validation vs. Google Maps: What’s the Difference?

Many of us use Google Maps to quickly verify that a location exists or give us an idea of what that location looks like. However, there is a common misconception that it will validate that the address found is correct and deliverable. So although Google Maps is an extremely powerful lookup tool, it will not validate addresses nor does it include the robust features and support included with our DOTS Address Validation-US service. To jumpstart your understanding and dispel some standard misconceptions, let’s explore some of the differences in our Address Validation service and Google Maps.

What Does DOTS Address Validation Do?

Although Service Objects can verify and validate many contact data points such as name, phone and email, our specialty is address validation. For us, addresses consist of business names, address fields, cities, states, and postal codes. Our USPS CASS Certified address validation service is designed to improve internal business mail processes and delivery rates by standardizing contact records against USPS data.

It’s All in the Documentation

Our Developer Guide is a great place to start for an in-depth breakdown of the service and response features for Address Validation. It is extremely useful while integrating and can be used as a reference guide as well when learning more about the information each output field conveys.

24/7 Support When Your Business Needs It Most

With the amount of information provided in the results, it is common to have questions along the road to understanding each of the outputs. Our team is here to help you in this process and provide 24/7 technical support. We can be reached by phone (805-963-1700), email and even live chat on our website. “Best Practice” and “Step by Step Tutorial” blogs are also posted on a regular basis.

Deliverability is Key

One of the biggest misconceptions about Google Maps and Address Validation is the ability to determine DEVLIVERABILITY. Beyond correcting and standardizing an address, our advanced algorithms and wide-reaching data sources allow us to determine if an address is deemed deliverable by the United States Postal Service. The service response will contain a Delivery Point Validation (DPV) indicator of 1-4 that can be used based on specific business logic. A DPV score of 1 indicates a perfectly deliverable address whereas a score of 2-4 indicates missing or incorrect inputs in the address field. The corrected address, component fields, and extra information such as the DPV indicator, residential delivery indicator (RDI), vacancy flags and more will be included and can be leveraged in your workflow.

Primarily, the locations that Google Maps will mark aren’t necessarily mail deliverable. There is a lot of leniency within the Google algorithms that allows for guess work to be made. Although Google can put a pin on the map for a given input address, it does not mean that a postal carrier will deliver mail at that location. However, if DOTS Address Validation marks a location as invalid, you can be sure you are getting genuine and accurate information.

When Is Google Maps Useful for Address Lookup?

With all of that said, Google Maps should not be discounted in its ability to investigate a location. If the image data was captured recently it can be used to understand why our service marked an address the way it did. A prime example of this is an address marked as having a “street number out of range.” By checking Google Maps data and cross referencing our service response, more light can sometimes be shed about that address location.

While you can use Google Maps to potentially confirm if a location exists, it is imperative to use robust validation tools like DOTS Address Validation to ensure any mail your business sends can actually be delivered, saving time and money.

If you have any questions about validating, verifying or appending addresses, or any other contact data points including name, phone, email and device, feel free to contact us.

Leverage Service Objects’ Industry Expertise to Reach Your Data Quality Goals

At Service Objects, we are fully committed to our customers’ success, which is a main factor in why over 90% of our business is from repeat customers. And with over 16 years of experience in contact validation, we have accumulated a broad base of industry expertise, created numerous best practices and are considered thought leaders in global data validation.

It is because of this knowledge that some of our customers turn to us when they lack the internal resources to carry out their data quality project. Whether it is assistance in implementing a data quality initiative, asking for customization to our products to meet specific business needs or help integrating our solutions into Marketing or Sales Automation platforms, Service Objects’ Professional Services can assist your business in achieving optimal results on your project in a quick and efficient manner.

Here are just three of the ways we can help:

Integration Programming and Code Support

If your team is overwhelmed or lacks the technical resources to integrate data quality solutions into your existing systems, Service Objects can step in and quickly get your project moving. We provide your team with the technical knowledge, support, and best practices needed to implement your chosen solution in a timely fashion and within your budget.

CRM or Marketing Automation Platform Integration

We have created cloud connectors for the leading sales and marketing platforms and have developed extensive knowledge on how these systems work with our data quality solutions. We enable your organization to implement best practices, allowing your business to verify, correct and append contact data at the point of entry. The result is your contact database contains records that are as genuine, accurate and up-to-date as they can possibly be.

Custom Services

Our engineers have years of experience creating, implementing and supporting data quality services in many different programming languages. As a result, we can customize our existing services to solve a challenge that is specific to your business. Our proactive support services team will work with your technical team to refine, test and implement the custom service to work for your business’ specifications.

These are just some of the ways we can help. For more information about how you leverage our industry expertise and technical knowledge, contact us.

Service Objects ColdFusion Integration Tutorial

As part of our commitment to making our data quality solutions easy to integrate, our Application Engineering team has developed a series of tutorials on how to integrate our services.  The series highlights various programming languages, with this tutorial exploring the “how-to’s” of applying our services using ColdFusion.

ColdFusion is a scripting language that has been around since 1995. It was created to make development of CGI scripts easier and faster.  ColdFusion has unique aspects, including use of its native ColdFusion Markup Language (CMFL for short) to allow HTML style tags for programming with systems. Like most things in the tech world, it can draw a lot of polarized opinions, where some are ardent supporters, and others, less than enthusiastic fans. If you fall in the supporter camp, and want to learn how to call a web service with ColdFusion, that is where our experts can step in and help.

To get started you will need a ColdFusion IDE (we’re using ColdFusion Builder 3) and a Service Objects’ License key. We’re using one for DOTS Lead Validation but you can follow along with your service of choice.

Project Setup

The first step is to launch your IDE and select an appropriate workspace for your project. Next, we will create a new project.

Select next for a blank template and then click next again.  On the following screen give your project an appropriate name and click finish.

Congratulations! You created a brand new ColdFusion project. Now it’s time to add some code. For starters, we’ll want to add a form and elements to initialize our form inputs so that we can create a sample page to input data to send to our web service. This likely won’t be what you will want to do in a live environment, but this is for demonstration purposes.

The DOTS Lead Validation service that we’re using has quite a few inputs so this may take a while. Once you are finished it should look like the following:

Making the Web Service Call

The next bit of code that we will add is to make the actual HTTP GET call to the Service Objects’ web service. Let’s use the CFML tags to make the actual web service call.

After the code makes the call to the trial.serviceobjects.com endpoint, we perform a failover check in the code. This failover check and the try catch blocks that it is nested in will help ensure that your integration of our web service will continue to work uninterrupted in the event that the primary web service is unavailable or not responding correctly.

The primary endpoint should be pointing to ws.serviceobjects.com and the backup endpoint should be pointed to wsbackup.serviceobjects.com.

Displaying the Results

Now that you have successfully called the web service, you will obviously want to do something with the results. For demonstration purposes we will simply display the results to the user.  You can use the code snippet below to display.

If you are having trouble figuring out how a particular output is mapped in the ColdFusion response, then you can use the <cfdump var=””> tag to dump the outputs onto the screen. This should allow for easy troubleshooting.

Now that our CFML is all set up, lets see an example input and output from the service. Below is sample lead information that you might encounter:

And here is some of the response that DOTS Lead Validation will return:

The DOTS Lead Validation service can return a multitude of information about your lead.  To download a trial key for any of our 23 contact validation solutions, please visit https://www.serviceobjects.com/products

P.S.  Here is the full ColdFusion script page in case you need it to get up and running.

 

Service Objects’ Application Engineers: Helping You Get Up and Running From Day 1

At Service Objects, one of our Core Values is Customer Service Above All. As part of this commitment, our Application Engineers are always available to answer any technical questions from prospects and customers. Whether users are beginning their initial investigation or need help with integration and deployment, our Engineers are standing by. While we continually make our services as easy to integrate as possible, we’d like to touch on a few common topics that are particularly helpful for users just getting started.

Network Issues

Are you are experiencing networking issues while making requests to our web services? It is a very common problem to face where outbound requests are being limited by your firewall and a simple rule update can solve the issue. When matters extend beyond simple rule changes, we are more than happy to schedule a meeting between our networking team and yours to get to the root cause and solve the issue.

Understanding the Service Outputs

Another common question revolves around the service outputs, such as how they should look and how they can be interpreted. From a high level, it is easy to understand what the service can provide but when it comes down to parsing the outputs, it can sometimes be a bit trickier. Luckily there are sets of documentation for every service and each of their operations. Our developer guides are the first place to check if you are having trouble understanding how individual fields can be interpreted and applied to your business logic. Every output has a description that provides insight into what that field means. Beyond the documentation, our Application Engineering team is available via multiple channels to answer your questions, including r email, live chat, and phone.

 Making the Move from Development to Production

Eventually everyone who moves from a being a trial user to a production user undergoes the same steps. Luckily for our customers, moving code from development to production is as easy as changing two items.

  • The first step is swapping out a trial license key to a production key.
  • The second step is to point your web service calls from our trial environment to our production environment. Our trial environment mirrors the exact outputs that you will find in production so no other code changes are necessary.

We understand that, even though we say it is easy, making the move to production can be daunting. That is why we are committed to providing your business with 24/7/365 technical support. We want the process to go as smoothly as possible and members of our team are standing by to help at a moment’s notice.

We have highlighted only a few broad cases that we have handled throughout our 16 years of providing genuine, accurate, and up-to-date data validation. Many technical questions are unique and our goal is to tackle them head on. If a question arises during your initial investigation, integration, move to production, or beyond, please don’t hesitate to contact us.

API Integration: Where We Stand

Applications programming interfaces or APIs continues to be one of the hottest trends in applications development, growing in usage by nearly 800% between 2010 and 2016 according to a recent 2017 survey from API integration vendor, Cloud Elements. Understandably, this growth is fueling an increased demand for API integration, in areas ranging from standardized protocols to authentication and security.

API integration is a subject near and dear to our hearts at Service Objects, given how many of our clients integrate our data quality capabilities into their application environments. Using these survey results as a base, let’s look at where we stand on key API integration issues.

Web service communications protocols

This year’s survey results bring to mind the old song, “A Little Bit of Soap” – because even though the web services arena has become dominated by representational state transfer (REST) interfaces, used by 83% of respondents, a substantial 15% still use the legacy Simple Object Access Protocol (SOAP) – a figure corroborated by the experiences of our own integrators.

This is why Service Objects supports both REST and SOAP among most if not all services. We want our APIs to be flexible enough for all needs, we want them to work for a broad spectrum of clients, and we want the client to be able to choose what they want, whether it is SOAP or REST, XML or JSON.  And there are valid arguments for both in our environment.

SOAP is widely viewed as being more cumbersome to implement versus REST, however tools like C# in Visual Studio can do most of the hard work of SOAP for you. Conversely, REST – being URL http/get focused – does carry a higher risk of creating broken requests if care is not taken.  Addresses, being a key component in many of our services, often contain URL-breaking special characters.  SOAP inherently protects these values, while REST on a GET call does not properly encode the values and could create broken URLs. For many clients, it is less about preference and more about tools available.

Webhooks: The new kid on the block

Webhooks is the new approach that everyone wants, but few have implemented yet. Based on posting messages to a URL in response to an event, it represents a straightforward and modular approach versus polling for data. Citing figures from Wufoo, the survey notes that over 80% of developers would prefer this approach to polling. We agree that webhooks are an important trend for the future, and we have already created custom ones for several leading marketing automation platforms, with more in the works.

Ease of integration

In a world where both applications and interfaces continue to proliferate, there is growing pressure toward easier integration between tools: using figures cited from SmartBear’s State of the APIs Report 2016, Cloud Elements notes that this is a key issue for a substantial 39% of respondents.

This is a primary motivation for us as well, because Service Objects’ entire business model revolves around having easy-to-integrate APIs that a client can get up and running rapidly. We address this issue on two fronts. The first is through tools and education: we create sample code for all major languages, how-to documents, videos and blogs, design reference guides and webhooks for various CRM and marketing automation platforms. The second is a focus on rapid onboarding, using multiple methods for clients to connect with us (including API, batch, DataTumbler, and lookups) to allow easy access while APIs are being integrated.

Security and Authentication

We mentioned above that ease of integration was a key issue among survey respondents – however, this was their second-biggest concern. Their first? Security and authentication. Although there is a move toward multi-factor and delegated authentication strategies, we use API keys as our primary security.

Why? The nature of Service Objects’ applications lend themselves well to using API keys for security because no client data is stored. Rather, each transaction is “one and done” in our system, once our APIs perform validation on the provided data, it is immediately purged from our system and of course, Service Objects supports and promotes SSL over HTTPS for even greater protection.  In the worst-case scenario, a fraudster that gains someone’s key could do transactions on someone else’s behalf, but they would never have access to the client’s data and certainly would not be able to connect the dots between the client and their data.

Overall, there are two clear trends in the API world – explosive growth, and increasing moves toward unified interfaces and ease of implementation. And for the business community, this latter trend can’t come soon enough. In the meantime, you can count on Service Objects to stay on top of the rapidly evolving API environment.

Testing Through Batches or Integration: At Service Objects, It’s Your Choice

More times than not, you have to buy something to really try it.  At Service Objects, we think it makes more sense to try before you buy.  We are confident that our service will exceed expectations and are happy to have prospects try our services before they spend any money on them.  We have been doing this from the day we opened our doors.  With Service Objects, you can sign up for a free trial key for any of our services and do all your testing before spending a single cent.  You can learn about the multiple ways to test drive our services from our blog, “Taking Service Objects for a Test Drive.” Today, however, I am focusing on batch testing and trial integration.

Having someone go through their best explanations to convey purpose or functionality can be worthwhile but, as the saying goes, a picture is worth a thousand words.  If you want to know how our services work, the best way to see them is simply try them out for yourself.  With minimal effort, we can run a test batch for you and have it turned around within a couple hours…even less time in most cases.  Another way we encourage prospects to test is by directly integrating our API services into their systems.  That way you see exactly how the services behave and get a better feel for our sub-second response times.  The difference between a test batch and testing through direct integration is the test batch will show the results and the test through integration will demonstrate how the system behaved to deliver results.

TESTING THROUGH BATCHES

Test batches are great.  They give you an opportunity to see the results from the service first hand, including all the different fields we return.  Our Account Executives are happy to review the results in detail and you always have the support of the Applications Engineering team to help you along.  With test batches, you can quickly see that a lot of information is returned regardless of the service you are interested in.  Most find it is far more information than expected and often clients find that the additional information helps them solve other problems beyond their initial purpose.  Another aspect that becomes clearer is the meaning of the fields. You get to see the fields in their natural environment and obtain a better understanding than the strict academic definitions.  Lastly, it is important to see how your own data fairs through the service and far more powerful to show how your data can be improved rather than just discussing it conceptually.  That is where our clients get really excited about our services.

TESTING THROUGH INTEGRATION

Testing through integration is a solid way to gain an understanding of how the service behaves and its results.  It is a great way to get a feel for the responses that come back and how long it takes.  More importantly, you can identify and fix issues in your process long before you start paying for the service.  Plus, our support team is here to assist you through any part of the integration process.  Our services are built to be straightforward and simple to integrate, with most developers completing them in a short period of time.  Regardless, we are always here to help.  Although we highly recommend prospects run their own records through the service, we also provide sample data to help you get started.  The important part is you have a chance to try the service in its environment before making a commitment.

Going forward with either of these approaches will quickly demonstrate how valuable our services are. Even more powerful is when you combine the two testing procedures with your own data for the best understanding of how they will behave together.

With all that said, if you’re still unsure how to best begin, just give us a call at 805-963-1700 or sign up for a free trial key and we’ll help you get started.

Introducing Service Objects New Open API

Service Objects is committed to constantly improving the experience our clients and prospective clients have with our data quality solutions. This desire to ensure a great experience has led us to revamp and redesign our lookup pages. These pages are easy to use and give all the information necessary for integrating and using our API in your application. This blog presents some of the key features.

Sample Inputs

One request we often receive is a quick sample lookup that will show our customers and prospects what to expect when calling our API. We are implementing just that in our new lookup pages.

In the example below, we are using our Lead Validation International lookup page. If the “Good Lead” or “Bad lead” link is selected, sample inputs will be filled into the appropriate fields. For this example we’ve selected, “Good Lead.”

We implemented this option so that users can get a quick idea of what types of inputs our services accept and what type of outputs the service will return. The form simply needs a license or trial key and it will return the validated data.

All Operations and Methods

Another benefit of these new pages is that they concisely and easily display all the methods available for an API along with all the potential HTTP methods that can be used to interact with the service.

If you want a JSON or XML response, select the appropriate GET operation and you will have everything you need to make a successful request to the service. If you want to make a POST request to the service, simply select the post operation and it will detail all that you need to have your data validated in your method of choice.

Detailed Requests and Responses

Arguably the most important pieces for a developer looking to integrate with an API would be to know how to make a request to the service, and what type of response to expect. These new lookup pages provide that information in a very easy way as shown below.

 

After making a sample request, you will see the URL used to fetch the validated data, the actual response from the web service, and the response headers that the service provides. These are all vital pieces of information that will have you up and running in no time. The new pages also list what type of response object will be returned from the service. This can be seen below the response body and headers.

Additional Resources

The page also offers up extra pieces of information that will assist with integration. The link to our developer guides, WSDL (for SOAP integrations) and host paths can be found on the page as well. These resources will help you have your application up and running as quickly as possible.

Feel free to sign up for a Service Objects trial key to test with our new look up pages!

Service Objects is the industry leader in real-time contact validation services.

Service Objects has verified over 3 billion contact records for clients from various industries including retail, technology, government, communications, leisure, utilities, and finance. Since 2001, thousands of businesses and developers have used our APIs to validate transactions to reduce fraud, increase conversions, and enhance incoming leads, Web orders, and customer lists. READ MORE