43 items tagged ”Development”

Smarty’s security and confidentiality approach is built around a simple idea: process address data in accordance with customer agreements and relevant privacy requirements, protect it, and limit who (and what) can access it. We recognize that you own your compliance requirements, and we’re here to make that easier. Below is a synthesized view of the controls and practices Smarty follows to support compliance, along with details on our Enhanced Data Privacy upgrade, which provides an extra layer of protection for you and your business or organization.

Geocoding can seem as simple as putting money in a vending machine and making a selection. You submit an address, and get coordinates back. In many instances, geocoding could be that straightforward. In business processes, coordinates influence fraud checks, delivery routing, compliance processes, customer experience, and risk decisions across industries like insurance, healthcare, logistics, fintech, and ecommerce. However, location signals are often too broad or "plausible. " The impact on your workflow is costly: mispriced risk, avoidable manual work, and harder-to-defend decisions.

SDK authors live in a permanent tug-of-war: Users want a simple constructor they can paste and ship. Maintainers want room to grow without breaking everybody’s build on the next release. That second part matters a lot right now, because a lot of people are still relatively early in their software careers. Approximately one in three developers has coded professionally for four years or less . That matters because unclear or fragile APIs disproportionately hurt newer developers—they don’t have scars yet.

If you’ve ever run into an address that seems to exist in more than one place, congratulations—you’ve discovered the world of ambiguous address matches. They’re the Schrödinger’s cat of location data: valid, yet potentially two distinct locations. This blog will focus on a few key things: What are ambiguous address matches? Why ambiguous address matches matter for compliance and customer service How to handle matches with address ambiguity Why you should inform your customers of ambiguous address matches Our final thoughts on ambiguous address matches What are ambiguous address matches? An ambiguous address match occurs when an entered address resolves to two or more valid locations with slight but meaningful differences.

For two days, Smarty users gathered together with other address data experts for Pinpoint, Smarty’s first virtual user conference, where developers, industry experts, and product specialists talked all things addresses and pulled back the curtain on address data solutions. Attendees asked questions about cloud-based software, the impact of accurate address data on fintech and insurance companies, and the ROI of good address data across all industries. Plus, attendees got to take a peek behind the scenes and see what makes Smarty’s address data solutions tick.

Once you know what capabilities you need, the next challenge is choosing a provider that actually delivers—pun intended. This blog is part of our five-part series, What to look for in an address data solution . Previously, we discussed the need to find an address data solution that understands the importance of speed, scalability, and reliability, enabling you to maintain automated, efficient, and accurate workflows in any industry that deals with addresses. Today, we’ll focus on the hidden costs of inaccurate data, defining and combating the “validation gap”, and why it’s important in any industry.

November 2025 | 100% online | 100% awesome Join us this November for the Smarty Virtual User Conference, a two-day event packed with insights, tools, laughs, and $1000 worth of prizes. This event is for you, whether you’re optimizing delivery accuracy, improving compliance, or just trying to figure out if your neighbor really has a breakfast nook. What to expect 2 days, 12 hours of content, zero fluff Live sessions from address data pros Hands-on demos of Smarty’s latest tools and plugins Giveaways galore, like gift cards, swag, and even a chance at a massive LEGO set Hidden Easter eggs throughout the event (no, seriously—find them and win) An after-party with games (shoutout to Brady Amundson) Tailored tracks for every role For developers Roll up your sleeves.

Burning the end of a brisket can lead to some tasty results (we’re looking at you, burnt ends), but unexpectedly burning through your lookups? Not so appetizing. All users receive notifications when their API usage reaches 90% and 100%. To help users further leverage their lookups, Smarty’s cooked up a solution: the ability to get notification emails when usage reaches three additional intervals: 25%, 50%, and 70%. With these notifications working alongside usage by key and limit by key , you can manage your API usage better.

Healthcare fraud isn’t just an occasional headache—it’s a $20 billion-a-year black hole draining financial institutions. And that’s just the fraud we know about. As healthcare systems become more complex, fraudsters are also getting smarter, faster, and more creative at exploiting vulnerabilities, especially in address verification. The healthcare industry is an easy target. Medical data can be more valuable than credit card numbers, billing systems are a tangled mess, and the sheer complexity of transactions creates endless opportunities for fraud to slip through unnoticed.

In 2024, it’s estimated that online purchases, or ecommerce, made up more than 20% of global retail , with 2. 77 billion people shopping online , and those numbers will only get bigger in the following years. With so much online shopping, more goods and services are being shipped than ever before—including during the height of the Sears catalog in 1970. Side note: If you’re reading this and you don’t know what the Sears catalog was or how much it impacted the average home, it’s worth taking a trip down memory lane and seeing how your elders used to shop.

Nerds. While programmers/coders/engineers are extremely clever, we've found they may not fully understand addresses. Sure, they're ready to talk about variables, loops, arrays, the scope of stuff, callbacks, hosting, events, overloading, pattern matching, packets, elements, and more. But if you point out that most house numbering starts at "1" and not "0," their heads may explode. We've worked with quite a few developers and helped them understand the facts around address data, beginning with our own engineers.

Webinar recap: Ready to take your web forms from "meh" to "wow"? In our recent webinar, we gave tips and tricks and demonstrated live coding magic. The essentials of Smarty's address autocomplete API JavaScript SDK magic made easy Integrating Smarty’s Address Autocomplete API using our JavaScript SDK is a breeze. Smarty also has SDKs for . NET, Android, Go, iOS, Java, PHP, Python, Ruby, and Rust, making setting up client credentials, building functions, and handling address lookups look like child’s play.

In our recent webinar, Gianmarco Rosborough , Smarty's legal counsel, provided valuable insights on smart practices and legal considerations for using address data. Smarty offers the most accurate and easy-to-implement address intelligence suite, processing billions of addresses daily with a reliable API. This tool helps businesses clean data, lower shipping costs, and enhance user experiences with exceptional support. If your organization works with addresses, it's important for you to be aware of the legal ramifications of storing bad address data.

We're delighted to announce that Smarty has been honored with the Silver Award in the Support Department of the Year category at the 13th annual Best in Biz Awards . We want to emphasize what this recognition means for you, our customers and partners. At Smarty, our primary focus is providing the best supported, documented, and easiest-to-implement address APIs and data. Winning Silver in the Support Department of the Year category speaks volumes about our commitment to delivering an outstanding customer experience .

Today, we spotlight Trey Rutter, our Dev/Ops IT Associate . Trey is the wizard behind the scenes, helping to ensure that our hardware and address data solutions work seamlessly to deliver accurate and reliable information. Let's get to know Trey better. What is the most surprising thing you learned about addresses after joining Smarty? I found it surprising how a ZIP Code can tell us so much. It's more than just 5 digits at the end of your address. When you were in elementary school, what did you want to be when you grew up? As a kid, I had dreams of being an archeologist.

Without looking it up, do you know how much insurance losses natural catastrophes caused in 2022? What's your guess? According to a report published by Swiss Re , the world's leading provider of reinsurance, "Natural catastrophes caused an estimated USD 115 billion of insured losses in 2022—coming in well above the 10-year average of USD 81 billion. " A number that large, leaves a lot of room for improvement. One of the biggest challenges insurance providers face is accurately predicting where and when these devastating disasters will occur so that they can take appropriate measures to mitigate losses.

June 27, 2023 – PROVO, UTAH - Smarty , the location data intelligence leader, has teamed up with Sapiens , a global provider of software solutions for the insurance industry, to help insurers take their business-critical location data to the next level. With access to Smarty's cutting-edge tools, Sapiens customers can now transform the way they underwrite policies, manage risk, and process claims. Leveraging Smarty's technology allows insurers to refine risk profiles, write more profitable policies, insure properties more effectively, and improve the claims lifecycle while simultaneously reducing costs, risk, and liability.

We brought out the big guns in the way of our Development Team Lead, Kent Gividen , in a webinar all about authenticating your APIs. He went over some of his most useful tips and tricks that he uses to ensure APIs are authenticated. Was it helpful? You betcha. You wanna get the SparkNotes? Read on. Common and not-so-common APIs to know about Kent began by outlining the APIs that he has run into the most in his years as a developer. Some of them he dug into a little deeper than others, but these are all useful to be aware of.

As you're evaluating potential new business software for your organization, inevitably, someone will bring up the cost. Your purchasing department will likely want to know if moving to the cloud is cheaper than on-premise solutions or vice versa. "Money doesn't grow on trees," they might remind you. To truly compare cloud vs on-premise costs, you should first calculate the total cost of ownership or TCO. The TCO is a financial estimate created to help buyers and owners determine the direct and indirect lifetime costs of a product or service.

One of the biggest questions in IT infrastructure planning is whether to go with on-premise or cloud software solutions. Each type of software comes with its own pros and cons. To help organizations choose the software that best fits their needs, we created an executive guide that walks you through 6 key factors and breaks down cloud and on-premise strengths and weaknesses for each factor. Download it here to learn about all 6 factors or read on for an overview of on-premise versus cloud software deployment speed and complexity.

There are two types of frequent errors: 401 "Authentication Required" errors, and 402 "Payment Required" errors. If you keep reading, you can learn about both, as well as these other hot topics: Status code 401 - Authentication required How to authenticate API requests Common mistakes in client-side requests Common mistakes in server-side requests Status code 402 - Payment required When in doubt, contact support Status code 401 - Authentication required If you're seeing this error there's a chance that there's an issue with your API key, there's a mistake inside your client-side request, or a mistake in the server-side request.

Have you ever tried to add a minor feature to your application only to discover that you’ll have to re-write large blocks of code first? Or maybe you’ve spent hours deciphering hundreds, or perhaps thousands, of lines of existing code just to find out a task only required two lines of additional code. If you’re like most developers, you’ve wasted countless, frustrating hours wading through immensely complicated code trying to force it to do things it wasn’t built for. In his presentation, Mike Manwill, Frontend Team Lead here at Smarty, discussed 5 principles to help you create stupidly-simple applications that are maintainable, extendable, and bug-resistant.

Many businesses now collect data online. One could argue that it is nearly impossible to succeed in modern business without some sort of online portal in which there is an exchange of information between the provider and the customer. But how do you ensure that the information being input by the customer (or potential customer) is accurate? While there is no way to ensure that Bobby Duncan doesn’t put “Sammy Sosa” in the name line on a form, there IS a way to ensure that he’s putting in a valid mailing address for you to mail his package to.

TLS (and its predecessor SSL) are cryptographic protocols that provide authentication and data encryption for clients connecting with web servers. As new vulnerabilities are discovered, older cryptographic protocol versions are deprecated to maintain secure environments. On Tuesday, January 21, 2020, Smarty will require clients to use TLSv1. 2 or greater to connect with Smarty APIs without interruption. Clients using TLSv1. 0 or TLSv1. 1 will no longer be able to connect. Please refer to our documentation for more information: https://www.

At approximately 1:30 PM Mountain Time (3:30 PM Eastern) on November 13, 2018, we observed a significant latency spike in our external monitoring tools configured to access the load-balancing tier of our cloud-based APIs. These monitoring tools provide end-to-end testing and simulate a complete user experience with our application. By design, our systems can easily process more than 25x the usual amount of traffic we receive. We do this because of our customer usage patterns, in which we may observe a 10-fold increase in traffic within a short period, usually a few minutes or even a few seconds.

It's been said that naming is one of the two hardest problems in computer science, along with cache invalidation and 'off-by-one' errors. (See what I did there?) Do you ever find yourself wondering what policies and practices you could adopt to make your life easier when reading code you wrote months ago? Or maybe you're up at night wishing you knew how to write code in such a way as to maximize adoption and convenience for your users? Well, look no further because we've anticipated the need, solved the problem, and now we're sharing our knowledge and wisdom at no charge, all out of the goodness of our hearts in this comprehensive, totally no-nonsense (nudge, nudge, wink, wink) style guide of Go naming conventions.

One topic that seems to come up repeatedly on Stack Overflow or other online forums is the topic of how to go get private dependencies. Specifically, if I have a private Git repository on Github or Bitbucket, how do I bring that code locally via the go get tool such that automated builds can produce a clean, consistent build without interaction from a user? This problem is largely solved for public Github dependencies but continues to be a challenge for private dependencies. To reiterate, if you're only cloning publicly available dependencies, you probably won't be reading this post.

Writing test functions in Go is easy: package stuff import "testing" func TestStuff(t testing. T) { t. Log("Hello, World!") } Running test functions is also easy: $ go test -v === RUN TestStuff --- PASS: TestStuff (0. 00s) stuff_test. go:6: Hello, World! PASS ok github. com/smartystreets/stuff 0. 006s Preparing shared state for multiple test functions is problematic. The usual recommendation is to use table-drive tests . But this approach has its limits . For us, xUnit is the ideal solution.

For the purpose of this article, consider the following CSV data, slightly modified from the docs for encoding/csv : csvData := strings. NewReader(strings. Join([]string{ , , , , }, "\n")) Here's how you read the data, line by line, using the Reader provided in that package: reader := csv. NewReader(csvData) for { record, err := reader. Read() if err == io. EOF { break } if err != nil { // handle the error. . . // break? continue? neither? } fmt. Println(record) } // Output: // [firstname lastname username] // [Rob Pike rob] // [Ken Thompson ken] // [Robert Griesemer gri] There are a few awkward elements to this approach: We are checking for io.

I was recently asked two interesting questions : Why did you move from GoConvey to gunit ? Are you recommending folks do the same? These are great questions, and since I'm a co-creator of GoConvey and the principal author of Gunit, I feel responsible for giving a thorough answer. For the impatient, here's the TL;DR: Question 1: Why did you move to gunit? After using GoConvey and feeling consistent friction with that approach, we came up with an alternate approach that was more aligned with what we value in a testing library and which eliminated said friction.

For this installment of the Testing in Go series we'll be talking about a grouping of packages that facilitate general-purpose comparisons in various contexts. Since the most common context is testing it seemed like this series was the right place for the discussion. We generally refer to these comparison functions as assertions ( cue ominous background music and spooky sound effects ). You may have already read the opinions found on the Golang FAQ related to assertions. "Why does Go not have assertions?" Go doesn't provide assertions.

Introduction TL;DR: Choose an approach to software testing that helps your organization create the best possible end results. That might mean using and/or creating a few tools and/or libraries along the way. Or, maybe not. What follows is a description of what we do at SmartyStreets, couched as a response to Dan Mullineux's equally valid way of doing things. The cost A favourite test helper library, with some simple test assertion functions clearly has some value. . . They [testing libraries] are not so bad, but they come at a cost, defer to avoid them.

I was given the task of setting up a tinc VPN so that we could test performance for comparison against other VPN systems. This task took much longer than it should have. For that reason, I am making this post to help me and others remember how to do it again in the future. Installing tinc is straightforward enough. You can download the latest release and build it or install it from your favorite package manager. The configuration for tinc lives in /etc/tinc . The configuration is what seems to be the hard part of getting tinc to work.

Not every server is made equally. On dedicated servers, the hardware varies widely. On virtual and cloud servers, the resource allocations also vary widely. Some servers are CPU-optimized for maximum computing power. Others focus on having a lot of memory. Some servers are built to have a good balance of all system resources. Hardware aside, we require many differing tasks of our servers. Some applications are processor hungry, some need large amounts of disk space, while others take up a lot of memory.

For this installment of the Testing in Go series I'll share a really nifty way to deal with time in your unit tests. When the behavior you are testing depends on the current time it can be tricky to assert on the results because the current time is a moving target. So, usually we end up resorting to approximations in our assertions that, while functional, always bother me a bit. In some cases, depending directly on the system's current time prevents acceptable test coverage. Consider this trivial example, which defines a calendar service with a method that identifies the current quarter of the current calendar year: File: calendar.

I think it's time for a slight detour. In part 1 we covered the basics of testing in go. In part 2 we covered a few slick ways to execute tests. In part 3 we covered some of our recent endeavors at Smarty to build on the basics. Toward the end of that post, we went into some detail regarding our approach to assertions. The assertions referenced in the GoConvey project are actually their own separate project that are imported into GoConvey. The nice thing about separating the assertions into their own separate project is that they can be used, well, separately.

This post contains additional data referenced from the original sex offender registry post . Records containing the following were excluded from our statistical analysis: [Click to return to article] state=?? and zip=00000 or 11111 street contains "not available" street contains "incarcerated" or "incac" or "incrc" or "incarc" street contains "prison" street contains "absconded" or "absconced" or "absc" street contains "detention" or "det" or "det ctr" or "det center" or "detain" or "dt ctr" street contains "deported" street contains "incarc" street contains "unknown" or "unk" street contains "deceas" or "deseas" street contains "jail" street contains "custody" street contains "immigration" street contains "transien" or "transnt" or "trnsnt" street contains "homeles" or "homles" street contains "inmate" street contains "out of state" street contains "xxx" street contains "failure" or "fail" street contains "fail" street contains "register" street contains "verif" street contains "behav" street contains "institut" or "inst" street is blank street contains "vicinity" street contains "fugit" street contains "no longer" street contains "correctio" or "corr" or "correct" street contains "complia" street contains "reform" street contains "block of" or "blk of" or "blk" state is blank and city contains "unk" street contains "&" street contains "underpass" street contains "offend" street contains "resident" street contains "between" city contains "unknown" AND zip contains "00000" street contains "moved" street contains "nonresident" street contains "unconfirmed" state and zip are same AND city is blank zip contains "jail" city contains "Not available" and zip is unintelligible as a zip street = city street contains " street + city + state has more than two entries street contains "complex" street contains "reincarc" city contains "convict" street contains "usp" street contains "penit" street contains "hosp" street contains "louis" and city is "St.

Review Welcome to part 3 of our "Testing in Go" series . If you're new here, feel free to catch up before reading on. In part 1 of this series I eluded to our perceptions of the standard testing tools provided by the Go tool and the standard library and what was missing for us . We all have different expectations of a testing tool and so it's no wonder that so many have been created . Part 2 of the series focused on how we have made the act of running tests effortless and automatic. Introduction In this post and the next few posts I'll focus on our approach to writing actual tests.

Here's part 1 of our "Testing in Go" series . Introduction Thinking about trying Go ? You won't regret it! It's great that testing is baked into the "testing" package from the standard library and the corresponding go test command (which has all sorts of useful and interesting flags ). We'd like to show you how easy it is to get started using the built-in testing tools and introduce you to some tools we've created. This is the first installment of a series designed to do just that. All you have to do is create a file named like _test.

Here's part 2 of our "Testing in Go" series . If you're new, feel free to catch up before reading on. Basics You've already learned how to execute tests in Go for a single package. $ go test There's a bit more to it, though. You can run any package from anywhere if you provide the import path. For example, this command runs the actual tests for the "testing" package from the standard library: $ go test -v testing If you've already run go get github. com/bradfitz/http2 you can execute those tests from anywhere with this: $ go test -v github.

You asked for it and now you've got it . For packages that pass all tests, coverage reports are generated and made available by clicking the package name, which in that case becomes a link (provided you've cleared your browser's cache!). Right now the coverage command that is run is something like this: $ go test -covermode=set -coverprofile=<packagename>. txt That command generates a plain text profile used in the following command: $ go tool cover -html=<packagename>. txt -o <packgename>.

One of the great benefits of TDD/BDD is that you usually don't have to spend much, if any time at all in a debugger. To enter a debugger is to admit a loss of control over the system under test. Even so, there are times when you do need to debug something, even if you're maintaining the discipline. Lately, most of my coding is in GoLang. Coming from using an IDE almost exclusively to write Python (using PyCharm) and C# (using VS and ReSharper), and knowing how great the visual debugging tools are it's hard to fathom using a console-based debugger for GoLang code.

It's now been a few months since I decided that the kind of testing tools I wanted for Go programming hadn't yet been created (or I just hadn't found them yet. . . ). So, about 4 months ago I started work on GoConvey and a month later came the first release. The coolest thing about GoConvey (other than the clean DSL , comprehensive set of built-in assertions , and the fact that it integrates fully with go test ) is the built-in auto-reloading web UI that reports your test results to your web browser whenever a relevant file is saved (HTML5 notifications included).