Forem: APIVerve

7 SSL Certificate Problems That Kill Trust

APIVerve — Mon, 16 Mar 2026 16:29:30 +0000

Nothing tanks user trust faster than a browser security warning. That red padlock, the "Your connection is not private" interstitial—most visitors won't click through it. They'll leave. And they probably won't come back.

SSL certificates are one of those things that work invisibly until they don't. And when they fail, they fail loudly. Here are seven problems that catch teams off guard, and how to spot them before your users do.

1. The Certificate Expired

This is the most common SSL failure, and the most preventable. Every SSL certificate has an expiration date. When that date passes, browsers immediately distrust the certificate and show a full-page warning.

It happens to everyone. Even massive companies have let certificates expire on production systems. The problem is that certificate renewal is easy to forget when it only happens once a year (or once every 90 days with Let's Encrypt). The person who set it up might have left the company. The auto-renewal might have failed silently. The credit card on file—or even the domain registration itself—might have expired.

The fix is monitoring. Use an SSL checker to check your certificates regularly and alert when expiration is approaching. Most teams set alerts at 30 days, 14 days, and 7 days before expiration. That gives you three chances to notice and act before anything breaks.

An SSL checker returns the valid_from and valid_to dates. Subtract today from valid_to and you know exactly how many days remain. If the number gets below your threshold, somebody needs to renew.

2. The Domain Doesn't Match

An SSL certificate is issued for specific domain names. A certificate for example.com doesn't cover app.example.com unless it's a wildcard certificate (*.example.com). And a wildcard for *.example.com doesn't cover example.com itself—that's a separate entry.

This mismatch happens most often during infrastructure changes. You spin up a new subdomain, point it to a server that already has an SSL certificate, and assume it's covered. It isn't. The browser checks whether the certificate's subject (or subject alternative names) includes the domain being accessed. If not, warning page. A quick DNS lookup can confirm which server a subdomain actually points to before you assume certificate coverage.

Checking the subject.CN (Common Name) and subjectaltname fields from a certificate reveals exactly which domains it covers. Before launching a new subdomain, verify the certificate includes it. Before migrating a domain to new infrastructure, confirm the new server's certificate matches.

3. Weak Encryption

Not all SSL certificates are equally strong. The encryption strength depends on the key size and the cipher suites the server supports.

A 2048-bit RSA key is the current minimum for browser trust. Older certificates with 1024-bit keys are considered insecure. Even certificates that are technically valid might use deprecated cipher suites that modern scanners flag as weak.

The bits field from an SSL check tells you the key size immediately. If you see 1024 or lower, that certificate needs replacement regardless of its expiration date. Modern certificates should use 2048-bit RSA at minimum, with 4096-bit as the recommended standard for anything handling sensitive data.

This matters beyond security. Google uses HTTPS as a ranking signal, and strong SSL configuration is part of that assessment. Weak encryption can quietly hurt your search rankings.

4. Certificate Chain Issues

SSL certificates don't exist in isolation. They're part of a chain: your certificate, signed by an intermediate certificate, signed by a root certificate that browsers trust. If any link in this chain is missing or broken, validation fails.

The most common chain issue is a missing intermediate certificate. Your certificate is valid. The root certificate is trusted. But the server doesn't serve the intermediate certificate that connects the two. Some browsers can fill in the gap by fetching the intermediate themselves. Others can't.

This creates the maddening situation where your site works in Chrome but not in Firefox, or works on desktop but not on mobile. Inconsistent failures across browsers almost always point to a chain problem.

An SSL check that includes CA issuer information reveals whether the chain is complete. If the check succeeds but specific browsers fail, look at the chain configuration on your server.

5. Mixed Content

You have a valid SSL certificate. Your site loads over HTTPS. But some resources on the page—images, scripts, stylesheets—load over plain HTTP. This is mixed content, and browsers handle it harshly.

Active mixed content (scripts, iframes) gets blocked entirely. Passive mixed content (images, audio) might load but triggers warnings. Either way, that green padlock disappears, replaced by a warning icon that tells users something is wrong.

SSL certificate checks won't catch this directly—it's a content problem, not a certificate problem. But it ends up on this list because developers blame the certificate first, every single time. If your certificate checks clean but users report security warnings, audit your pages for HTTP resource references.

The fix is usually straightforward: change http:// to https:// in your resource URLs, or better yet, use protocol-relative URLs (//) that inherit the page's protocol.

6. The Wrong Certificate Type

Different certificate types provide different levels of validation.

Domain Validation (DV) certificates confirm you control the domain. They're automated, free (via Let's Encrypt), and sufficient for most applications. The certificate shows the domain name but no organization information.

Organization Validation (OV) certificates verify the organization behind the domain. The CA checks that the company exists and controls the domain. The certificate includes the organization name.

Extended Validation (EV) certificates involve the most rigorous verification. The CA verifies legal existence, physical address, and operational presence. These used to show a green bar in browsers (most no longer do), but they still convey maximum trust for high-stakes applications.

The issue isn't that one type is "wrong"—it's using the wrong type for your context. An e-commerce site processing payments should probably have OV or EV, not just DV. A personal blog? DV is more than enough. Financial institutions often require EV for regulatory compliance.

The issuer and subject fields reveal the certificate type. DV certificates show minimal subject information. OV and EV certificates include organization details—country, state, company name.

7. Certificate Revocation

Certificates can be revoked before they expire. This happens when private keys are compromised, the CA made an error, or the domain ownership changed. Revoked certificates should not be trusted, even if they haven't expired.

Revocation checking is, frankly, one of SSL's worst-designed aspects. Two mechanisms exist: CRL (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol). Both have reliability issues. CRLs can be large and slow to download. OCSP responders can be unreachable.

OCSP stapling improves this by having the server attach a recent OCSP response to the SSL handshake. Clients don't need to contact the OCSP responder separately. If your server supports OCSP stapling, enable it.

The infoAccess field from a certificate check shows the OCSP URI—where revocation status can be verified.

Automating the Checklist

Manually checking certificates doesn't scale. If you manage more than a handful of domains, automate these checks.

const response = await fetch(
  'https://api.apiverve.com/v1/sslchecker?domain=yourdomain.com',
  { headers: { 'x-api-key': 'YOUR_API_KEY' } }
);
const { data } = await response.json();

// data.valid_from → certificate start date
// data.valid_to → certificate expiration date
// data.bits → key strength (2048, 4096, etc.)
// data.issuer.O → certificate authority name
// data.subject.CN → domain the cert covers

Run this daily against every domain you manage. Alert on certificates expiring within 30 days. Flag any certificate with key strength below 2048 bits. Log changes to detect unexpected certificate swaps.

Most SSL failures are preventable. They happen because nobody was watching. A daily automated check turns "surprise outage" into "routine maintenance."

Monitor your SSL certificates with the SSL Checker API. Verify TLS configuration with the TLS Checker API. Track domain expirations with the Domain Expiration API. Stay ahead of security issues.

Originally published at APIVerve Blog

Take Your App Multilingual (No Rewrite)

APIVerve — Mon, 16 Mar 2026 16:19:50 +0000

"We should support Spanish" is a sentence that strikes fear into engineering teams. Not because translation is conceptually hard, but because retroactively adding language support to an app built entirely in English feels like it requires rearchitecting everything.

It doesn't. At least, not all at once.

There's a pragmatic middle ground between "English only" and "fully localized in 40 languages." Most teams never find it because the discussion jumps straight from "we need Spanish" to "okay, let's implement i18n across the entire codebase." That's a months-long project. There are faster ways to start.

Start With the Content, Not the UI

The typical internationalization approach starts with the UI framework. Extract every string into a translation file. Set up locale routing. Configure date and number formatting. This is the right end state, but it's the wrong starting point for most teams.

Start with user-facing content instead. The parts of your application where language actually matters to the user experience. Product descriptions. Help articles. Email notifications. Error messages. Onboarding flows.

These are the places where a non-English speaker hits a wall. They might tolerate an English navigation bar—button labels are often recognizable across languages. But a help article that explains a critical feature? An error message that tells them what went wrong? Those need to be in their language.

Translating content is a much smaller, more contained project than internationalizing an entire UI framework. And it delivers most of the user value.

Machine Translation Has Gotten Good

Five years ago, machine translation was a punchline. Google Translate could turn a French restaurant menu into surrealist poetry. Professional human translators were the only serious option.

That's changed. Modern machine translation handles most European and major Asian languages well. It's not perfect—it struggles with idioms, cultural references, and highly technical jargon. But for straightforward content like product descriptions, support articles, and transactional emails, the quality is genuinely usable.

The key is knowing where machine translation works and where it doesn't.

It works well for: factual content, technical documentation, transactional messages (order confirmations, shipping notifications), knowledge base articles, and structured data with predictable patterns.

It works poorly for: marketing copy that relies on wordplay, legal documents where precision is critical, creative content that depends on cultural context, and anything where tone is as important as meaning.

For the first category, machine translation gets you 80-90% of the way there. For the second, you still need human translators—but that's a much smaller volume of content.

Detect Before You Translate

Before you translate anything, you need to know what language your users actually want. Guessing wrong is worse than not translating at all. There are several signals.

Browser language headers are the most reliable automatic signal. Every HTTP request includes an Accept-Language header that lists the user's preferred languages. If the header says es-MX,es;q=0.9,en;q=0.8, the user prefers Mexican Spanish, then general Spanish, then English.

Account settings let users explicitly choose. This is the gold standard—direct user preference. But it only works for logged-in users who've configured their settings.

Content language detection handles user-generated input. When a user submits a support ticket or fills out a form, detecting the language of their text tells you how to respond. If they wrote in Portuguese, respond in Portuguese.

Geographic signals are a rough proxy. A user in Japan probably prefers Japanese. But this fails for expatriates, travelers, and multilingual countries like Switzerland or India. Don't force language based on location—use it as a default that users can override.

The pragmatic approach layers these signals: use account settings if available, fall back to browser headers, and detect content language for user-generated text.

What to Translate First

You can't translate everything at once. So what earns priority?

Onboarding flows are the highest priority. A user who can't understand the signup process won't become a user. If your signup, login, and initial setup are translated, you capture users who would otherwise bounce.

Transactional emails come next. Order confirmations, password resets, billing notifications—these are messages users need to understand to use your service. A password reset email in a language you don't read is useless.

Error messages might be third. Think about how frustrating it is to get an error you can read. Now imagine it's in a language you don't understand. If a payment fails and the error message is in English, a Spanish-speaking user has no idea what to do next. Translated errors reduce support ticket volume significantly.

Help documentation and support articles address self-service. If users can find answers in their language, they don't need to contact support. This scales better than hiring multilingual support staff.

Marketing pages are last in priority but first in visibility. Your homepage and pricing page are what prospective users see. But prospects who don't read English probably found you through localized search results, which means they need localized landing pages.

The Translation API

Translating content programmatically keeps the process automated:

const response = await fetch('https://api.apiverve.com/v1/translator', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    text: 'Your payment was processed successfully.',
    target: 'es'
  })
});
const { data } = await response.json();
// data.translatedText → "Su pago fue procesado exitosamente."
// data.sourceLang → "en"

Notice the source parameter is optional. When omitted, the API auto-detects the source language. This is useful when processing user-generated content where you don't know what language they wrote in.

Storing Translations

Where do translated strings live? This depends on your architecture.

Alongside the original content is simplest. If your product descriptions are in a database, add a locale column and store translated versions as separate rows. Same content ID, different locale.

In translation files works for UI strings. JSON files keyed by locale (en.json, es.json, fr.json) are the standard i18n approach. Most frontend frameworks have built-in support for this pattern.

Generated on the fly works for content that changes frequently or where the translation doesn't need to be perfect. Real-time translation of support chat messages, for example. The user sees the translation immediately, even if it's not hand-polished.

Cached after first translation balances cost and freshness. Translate content the first time it's requested in a given language, cache the result, and serve from cache thereafter. This limits API calls while keeping translations available.

The right approach often combines these. Static UI strings in translation files. Database content with locale columns. Real-time translation for chat and user-generated content.

Languages to Start With

Choosing which languages to add first is a business decision, not a technical one.

Check your analytics. Where are your existing users? If 15% of your traffic comes from Spanish-speaking countries, Spanish is the obvious first language. If you have growing traffic from Brazil, Portuguese.

Consider your market strategy. Expanding into a specific region? Translate for that region's languages before you launch there, not after.

Think about language reach. Spanish covers 20+ countries. French covers parts of Europe, Africa, and the Americas. Mandarin covers the world's largest population. Arabic covers a wide geographic band. These high-reach languages provide the most return per translation investment.

Also consider language similarity. If you've already translated to Spanish, Portuguese is a smaller incremental effort—the languages share significant vocabulary and structure. This is one of those rare cases where the second step is genuinely easier than the first.

Translation Quality Over Time

Machine translation is a starting point, not a final state. Over time, improve translations using feedback.

Let users flag bad translations. A small "Suggest better translation" link gives bilingual users a way to contribute. Crowdsourced corrections improve quality organically.

Review high-traffic pages with human translators. Your homepage, pricing page, and checkout flow deserve professional translation. The cost is modest and the impact on conversion is measurable.

Track support tickets by language. If Spanish-speaking users consistently contact support about a specific feature, the translated documentation for that feature probably needs work.

Translation quality is a spectrum, not a binary. Shipping an 80% translation today beats shipping a perfect one six months from now. The users you'd lose in those six months aren't coming back.

Translate content with the Translation API. Detect languages with the Language Detection API. Reach a global audience without starting from scratch.

Originally published at APIVerve Blog

Extract Clean Content from Any Webpage

APIVerve — Mon, 16 Mar 2026 16:16:49 +0000

Open the source of any modern webpage. What you'll find is thousands of lines of HTML—navigation bars, footers, sidebars, ad containers, tracking scripts, cookie banners, newsletter popups, social sharing widgets. Buried somewhere in that noise is the actual content. The article. The documentation. The information someone actually came to read.

Extracting that content cleanly is a problem developers run into constantly. Whether you're building a read-later app, migrating content between platforms, feeding text to an AI model, or archiving information for research, you need the content without the cruft.

Why Raw HTML Is Useless

You might think fetching a webpage and stripping the tags gives you the content. Try it on any real webpage and you'll understand why that doesn't work.

A typical blog post lives inside a <main> or <article> tag, but it's surrounded by dozens of <div> elements containing things that aren't the content. The navigation has text. The footer has text. The sidebar has text. Related article sections have text. Cookie consent banners have text. All of it is valid HTML, and none of it is the article.

Stripping tags removes the structure but keeps all the noise. You end up with the article text mashed together with navigation links, footer disclaimers, sidebar promotions, and whatever else lives on the page. Completely unusable.

Proper content extraction requires understanding what the page is about and isolating the primary content from everything else. This is a surprisingly hard problem that's been studied for over a decade, with algorithms like Readability (the one behind Firefox's Reader View) and various boilerplate detection methods.

Markdown as the Output Format

Why Markdown specifically? Because it preserves structure while being universally portable.

HTML preserves structure too, but it carries presentation concerns. CSS classes, inline styles, framework-specific attributes—all tied to the original site's design system. Moving HTML between systems means cleaning up all that presentation baggage.

Plain text loses structure entirely. Headings become regular lines. Links lose their URLs. Lists become indistinguishable from paragraphs. You can't tell where a section begins or what's emphasized.

Markdown sits in the sweet spot. It preserves headings (##), links ([text](url)), lists, bold/italic emphasis, and code blocks. But it carries zero presentation information. It renders cleanly in any Markdown-capable system—GitHub, Notion, static site generators, documentation platforms, or even a plain text editor.

This makes Markdown the ideal intermediate format. Extract from any source, output Markdown, then render it however you need. Think of it as plain text that didn't skip leg day—just enough structure to be genuinely useful.

Use Case: Content Migration

Moving content between platforms is one of the most common reasons to extract web content.

Say you're migrating a blog from WordPress to a static site generator like Astro, Hugo, or Next.js. Your old posts are in WordPress's HTML format, complete with WordPress-specific shortcodes and CSS classes. Your new platform wants Markdown files.

You could export the WordPress database and parse the HTML. But that gives you WordPress-flavored HTML full of wp-block-* classes and shortcode syntax that no other platform understands.

The cleaner approach: point a content extractor at each published URL and get back clean Markdown. The extractor ignores the WordPress theme, the sidebar widgets, the comment sections. It pulls the article content and converts it to portable Markdown that works anywhere.

This works for any source platform. Migrating from Medium? From Ghost? From a custom CMS? If the content is accessible via URL, it can be converted to Markdown.

Use Case: AI and LLM Pipelines

Large language models need clean text. Feed them a raw HTML page and they waste context window on navigation menus, script tags, and boilerplate. Feed them extracted Markdown and they get the actual content with structural context preserved.

This matters enormously for retrieval-augmented generation (RAG) systems. Garbage in, hallucinations out. When your application retrieves web pages to answer user questions, the quality of the retrieved content determines the quality of the answer. If the retrieved "content" is mostly navigation links and cookie banners, the model's response will be confused or hallucinated.

Markdown extraction cleans the input pipeline. Each URL becomes a clean document with headings, paragraphs, and links—exactly what the model needs to generate useful responses.

The word count in the response also helps you manage context windows. If the extracted content is 5,000 words and your model context is 8,000 tokens, you know you need to summarize or chunk the content before including it. Without word count metadata, you're guessing at token usage.

Use Case: Research and Archiving

Web content disappears. Pages get taken down, domains expire, companies shut down, articles get edited. If you need to reference web content later—for research, compliance, or legal purposes—you need to save it.

Archiving as Markdown has advantages over saving HTML or screenshots. Markdown files are tiny (kilobytes versus megabytes for full HTML with assets). They're searchable with basic text tools. They're version-controllable with Git. They render in any text editor.

A research workflow might look like: find relevant articles, extract each to Markdown, save with metadata (source URL, extraction date, word count), and organize in a searchable archive. Months later, you can search your archive, find the relevant document, and cite it with the original URL—even if the original has since been taken down.

Use Case: Read-Later and Digest Tools

Pocket, Instapaper, and similar read-later tools solve the same core problem: extract the readable content from a webpage and present it cleanly. Building a custom version of this—whether for personal use, a team knowledge base, or a customer-facing feature—requires content extraction.

Newsletter digests work similarly. Aggregate content from multiple sources, extract the articles, summarize or truncate them, and compile into a single readable email or document.

The word count from extraction helps with digest curation. If your weekly digest should take 10 minutes to read (roughly 2,500 words), you can select articles that fit within that budget and trim or summarize others.

What Good Extraction Looks Like

A well-extracted page preserves several things:

Headings maintain their hierarchy. The article's H1, H2, and H3 structure carries over to Markdown heading levels. This lets you navigate the document, generate a table of contents, or break the content into sections.

Links survive as Markdown links with their original URLs. If the article references external sources, those references remain clickable. For content migration, this means your internal links can be updated to new URLs in a search-and-replace pass.

Lists stay as lists. Bullet points and numbered lists render as Markdown lists rather than being flattened into paragraphs.

Code blocks are preserved when present. Technical documentation often includes code examples, and losing those to paragraph formatting would destroy the content's utility.

Images are referenced but not downloaded. The Markdown includes image references with the original URLs. You can download and re-host images separately if needed. This keeps the extraction lightweight and fast.

The Extraction Call

Extracting a webpage to Markdown is a single POST request:

const response = await fetch('https://api.apiverve.com/v1/urltomarkdown', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    url: 'https://example.com/blog/interesting-article'
  })
});
const { data } = await response.json();

// data.title → "The Interesting Article"
// data.markdown → "# The Interesting Article\n\nFirst paragraph..."
// data.wordCount → 2847
// data.linkCount → 14

The response includes the page title, the full Markdown content, and metadata about what was extracted—word count, image count, and link count. This metadata helps you decide what to do with the content before processing it.

Dealing with Edge Cases

Not every webpage extracts cleanly. Some edge cases to be aware of.

JavaScript-rendered content is the biggest headache. Single-page applications that render content entirely in JavaScript after page load don't serve readable HTML in the initial response. The extraction sees the JavaScript bundle, not the rendered content. Most traditional websites, blogs, documentation sites, and news outlets serve HTML directly and extract well.

Paywalled content returns only what's publicly visible. If an article shows the first three paragraphs and hides the rest behind a paywall, that's all the extraction will capture.

Heavy advertising can confuse extraction algorithms. Pages where ads are interspersed with content might include some ad text in the output. This is rare with good extraction, but it happens on particularly ad-heavy sites.

Non-article pages like homepages, category pages, and search results don't have a single "article" to extract. The extraction might return navigation text or a collection of snippets rather than coherent content. These pages aren't good extraction targets.

For anything production-facing, validate extraction results. Check that the word count is reasonable (an article with 50 words almost certainly extracted poorly), that the title was found, and that the Markdown contains actual content. If you only need plain text without formatting, a website-to-text conversion is a lighter alternative worth considering.

Extract web content cleanly with the URL to Markdown API. Get plain text with the Website to Text API. Scrape links with the Link Scraper API. Build content pipelines that work with any source.

Originally published at APIVerve Blog

Enrich Your CRM with Public Company Data

APIVerve — Mon, 16 Mar 2026 16:11:59 +0000

Sales reps hate data entry. Every minute spent googling a company's address, looking up their ticker symbol, or figuring out what industry they're in is a minute they could spend actually selling.

CRM records with missing fields are a universal problem. A lead comes in with a company name and an email. That's it. No industry, no address, no exchange information, no SIC code. The rep is supposed to fill all of that in before their next call. They won't. The CRM stays sparse, reporting stays useless, and nobody trusts the data.

Data enrichment fixes this by pulling company information automatically. When a lead mentions they work at a public company, you can look up everything the SEC knows about that company in real time—and it's a lot.

The SEC Already Did the Research

The SEC requires public companies to file detailed information. Every US-listed company has a Central Index Key (CIK), and their filings include corporate metadata that's remarkably useful for sales and business intelligence.

From a single ticker symbol or company name, you get:

The legal company name as registered with the SEC. This matters more than you'd think. Your lead might say "Google," but the SEC filing says "Alphabet Inc." Contracts, proposals, and invoices need the legal name.

The SIC code and industry description. Standard Industrial Classification codes categorize companies by their primary business activity. SIC 3571 is "Electronic Computers." SIC 7372 is "Prepackaged Software." This tells your sales team what vertical the prospect is in without anyone having to research it.

The stock exchange where the company trades. NYSE, Nasdaq, or other exchanges. For some sales teams, exchange listing is a proxy for company size and legitimacy.

Physical addresses—both mailing and business headquarters. Knowing where a company is headquartered helps with territory assignment, timezone awareness, and compliance with regional regulations.

The phone number from their SEC filing. It's the corporate number, not a sales line, but it's a verified contact point.

State of incorporation. Delaware, Nevada, and a few other states are disproportionately popular. This matters for legal teams drafting contracts and for compliance workflows.

Fiscal year end. If you sell to finance teams, knowing when their fiscal year closes tells you when budget decisions happen. A company with a June fiscal year makes purchasing decisions on a completely different timeline than one ending in December.

Former company names. Companies rename. Mergers happen. Your CRM might have the old name. The API tells you what the company used to be called, helping you reconcile records.

Four Lookup Methods, One Response

Not every lead arrives with the same information. Sometimes you have a ticker symbol. Sometimes just a name. Doesn't matter—the API handles all of these.

Ticker lookup is the most precise. If someone mentions they work at a company and you know the ticker—AAPL, MSFT, TSLA—you get an exact match. No ambiguity. One ticker, one company.

CIK lookup is how regulators reference companies. If you're integrating with other SEC data sources or financial systems, CIK numbers are the canonical identifier. Think of it as the company's "social security number" in the SEC system.

Name search handles the fuzziest input. A lead says "I work at Apple" and you search for "Apple." You'll get results that match, and you pick the right one. Name search uses prefix matching, so "Micro" returns Microsoft, Micron, and other companies starting with those letters.

SIC code search flips the whole thing around. Instead of looking up one company, you list all companies in a specific industry. SIC 7372 returns every publicly traded prepackaged software company. Want to build a prospect list for an entire vertical in one call? This is how.

Enrichment in Practice

The real value of company data isn't in individual lookups—it's in automated enrichment that runs behind the scenes.

When a new lead enters your CRM, you extract the company name from their email domain or from what they entered in a form. You search the company name against the API. If there's a match, you populate CRM fields automatically.

This happens without the sales rep doing anything. They open the lead record and the industry, address, phone number, and other fields are already there. The rep can focus on the conversation, not the data entry.

For existing CRM records, run a batch enrichment process. Export records with missing fields, look up each company, fill in the gaps, and import back. A CRM with 10,000 leads that's 60% complete suddenly becomes 90% complete overnight. That's the kind of improvement that makes a sales manager's week.

The enrichment also serves as a data quality check. If a lead claims to work at "Apple" but the email domain is a personal Gmail, that's worth flagging. If the company name doesn't match any SEC filing, it's either a private company (useful to know) or possibly fake.

Building Sales Intelligence

Raw company data is nice. Combined company data is where it gets interesting.

Industry segmentation using SIC codes lets you analyze which industries your product sells best in. If 40% of your closed deals are in SIC codes related to financial services, that tells your marketing team where to focus campaigns. It tells your sales team which leads to prioritize.

Geographic analysis using business addresses reveals where your customers cluster. Three enterprise clients in Chicago might justify a local sales presence. A concentration in a particular state might make a regional conference worth attending.

Fiscal year timing drives sales strategy. Companies with December fiscal year ends make buying decisions in Q3 and Q4. Companies with June year ends buy in Q1 and Q2. If your CRM knows every prospect's fiscal year, your sales team can time outreach to land when budgets are being set.

Company name reconciliation catches duplicates. If your CRM has records for both "Alphabet Inc" and "Google LLC," the API's former names and ticker data help you recognize they're the same entity. Deduplication improves forecasting accuracy.

One API Call

The technical side is minimal. Here's what a ticker lookup returns:

const response = await fetch(
  'https://api.apiverve.com/v1/companylookup?ticker=AAPL',
  { headers: { 'x-api-key': 'YOUR_API_KEY' } }
);
const { data } = await response.json();

// data.name → "Apple Inc"
// data.sic → "3571"
// data.sicDescription → "Electronic Computers"
// data.exchanges → ["Nasdaq"]
// data.addresses.business.city → "Cupertino"
// data.fiscalYearEnd → "0928"

Four lookup methods, same response structure. Pick whichever matches the data you already have.

Beyond Public Companies

A natural question: what about private companies? The SEC only covers publicly traded companies—roughly 10,000 US entities. If your prospects are primarily startups or small businesses, SEC data won't cover them.

But for B2B sales teams selling to mid-market and enterprise companies, the coverage is substantial. These are the companies spending significant budgets, and they're almost all publicly listed or subsidiaries of public companies.

For the private companies in your CRM, the failed lookup itself is useful information. A "not found" is still a data point. Knowing a prospect is private affects how you position pricing, what competitive intel is available, and how the sales cycle might differ.

Data Freshness

SEC filings update regularly. Companies file quarterly and annually, and the data refreshes accordingly. This means the API reflects current information—current addresses, current phone numbers, current SIC codes.

Companies occasionally reclassify their industry, change their headquarters, or rename. The API tracks these changes. This is one reason periodic re-enrichment matters. A company that moved headquarters six months ago should have the new address in your CRM.

Look up any public company with the Company Lookup API. Search by ticker, name, CIK, or SIC code. Enrich your CRM, build prospect lists, and stop making sales reps do data entry.

Originally published at APIVerve Blog

Business Day Math Is Harder Than You Think

APIVerve — Mon, 16 Mar 2026 16:08:58 +0000

Quick: how many business days are in March 2026?

If you answered 22, you skipped weekends but forgot that different countries have different holidays in March. The US doesn't have a federal holiday in March, so 22 is correct there. But India celebrates Holi. Mexico has Benito Juárez's birthday. Japan has Vernal Equinox Day.

The correct answer depends entirely on where your users are. And that's just the beginning of why business day calculations are more complex than they appear.

The Weekend Problem

"Weekdays are Monday through Friday" is a reasonable assumption if your entire user base is in the Western world. It's wrong for about two billion people.

In many Middle Eastern countries, the traditional work week runs Sunday through Thursday. Friday and Saturday are the weekend. In some countries, the weekend is Friday and Saturday. Others use Saturday and Sunday. A few have only a single-day weekend.

Saudi Arabia, the UAE, and several other Gulf states recently shifted to a Saturday-Sunday weekend to align with global financial markets. But the transition wasn't instantaneous—some sectors still observe different schedules. Building "weekend" logic as a hardcoded Saturday-Sunday check will produce wrong results for a meaningful portion of the global workforce.

The pattern here is the same one that plagues all internationalization: assumptions that feel universal but aren't.

Holidays Break Everything

Even once you've sorted out weekends, holidays introduce a whole new layer of complexity.

National holidays vary by country—obviously. Less obviously, they vary by region within countries. The US has federal holidays, but individual states have additional ones. Germany's holidays differ by Bundesland. Canada's provinces don't all observe the same holidays.

Some holidays move. Easter is the most famous moveable holiday, but plenty of others shift year to year. Holidays based on lunar calendars (Eid, Chinese New Year, Diwali) fall on different Gregorian calendar dates each year. A holiday calculator that works for 2026 might be wrong for 2027.

Some holidays have substitute rules. In Japan, if a national holiday falls on a Sunday, the following Monday becomes a holiday. In the UK, bank holidays falling on weekends are "moved" to the next working day. These substitution rules differ by country.

And then there are the one-time holidays. Royal funerals, national celebrations, election days. These can be declared with short notice, and no algorithm can predict them. The UK had a one-off bank holiday for the Queen's funeral in 2022. Japan had extra holidays for the Emperor's enthronement in 2019.

Any system that calculates business days needs a holiday database that's actively maintained—not a formula.

Why This Matters in Software

Business day calculations aren't academic. They affect real money and real deadlines.

SLA commitments are measured in business days. "We'll respond within 2 business days" means something very different if you count holidays versus if you don't. A support ticket filed on Wednesday before a three-day weekend might not be due until the following Tuesday—but only if your system knows about the holiday.

Payment terms like "Net 30" sometimes mean 30 business days, sometimes 30 calendar days. The distinction matters for cash flow management. A vendor expecting payment in 30 business days is actually giving you about six weeks of calendar time.

Shipping estimates that say "3-5 business days" need to exclude weekends and holidays. A package shipped on the Friday before a Monday holiday doesn't arrive until at least Thursday—five calendar days but only three business days in transit.

Financial settlement follows strict business day rules. Stock trades settle on T+1 (one business day after the trade). Bond settlements are T+2. Getting these wrong has regulatory and financial consequences.

HR and payroll systems calculate everything from PTO accrual to payroll dates based on working days. A payroll that runs on the "last business day of the month" needs to know when that actually is.

The Cross-Border Headache

This is where most teams throw up their hands.

Consider a contract between a US company and a German supplier. The contract says "delivery within 10 business days." Whose business days? The US celebrates Independence Day on July 4th. Germany doesn't. Germany celebrates Tag der Deutschen Einheit on October 3rd. The US doesn't.

International businesses generally specify which country's calendar governs. But if your application calculates deadlines automatically, it needs to know which calendar to use for each transaction. A single "business days" calculation might need different holiday calendars depending on which parties are involved.

Payment processing across borders faces this constantly. A wire transfer between New York and London might be delayed by a US holiday that the UK doesn't observe, or vice versa. Both banking systems need to be open for the transfer to process. Miss this, and money sits in limbo while everyone points fingers at the other side.

The API Approach

Maintaining your own holiday database is possible but tedious. Holidays change. Countries add holidays, remove them, or change the dates. Regional variations multiply the complexity.

An API handles this by maintaining the data externally:

const response = await fetch(
  'https://api.apiverve.com/v1/workingdays?country=US&year=2026&month=3',
  { headers: { 'x-api-key': 'YOUR_API_KEY' } }
);
const { data } = await response.json();

// data.workingDaysCount → 22
// data.nonWorkingDays → [{ date: "2026-03-01", reasons: ["weekend"] }, ...]
// Each non-working day includes the reason: "weekend" or the holiday name

The response tells you not just the count but the specific dates and reasons. A weekend is different from a holiday in some business contexts—some contracts count weekends but not holidays, or vice versa.

Common Mistakes

Hardcoding holidays. Every developer thinks this will be fine. It never stays fine. A list of holidays that was correct when written becomes wrong within a year. If you must maintain a local list, treat it as data that requires annual updates, not code.

Ignoring regional holidays. National holidays are the minimum. If your users are in Bavaria, Bavarian holidays matter. If they're in Quebec, Quebec holidays matter. The difference can be several days per year.

Assuming "business day" means the same thing everywhere. It doesn't. In some industries and countries, Saturday is a half working day. Some count it as a full working day. Banking, retail, and government often have different definitions even within the same country.

Forgetting timezone boundaries. When it's already Friday in Tokyo, it's still Thursday in New York. If your deadline is "5 business days from today," the definition of "today" depends on where the user is.

Not handling the "next business day" edge case. What's the next business day after December 31st? Good luck. It depends on the year and country. Some countries have holidays on January 2nd. Some have extended New Year breaks. The answer might be January 3rd, 4th, or even later.

How Much Precision Do You Need?

Not every application needs per-country holiday awareness. A project management tool where all users are in one country can use that country's calendar and be fine. A personal todo app might not need business day calculations at all.

But any application that deals with contractual deadlines, financial settlements, international operations, or SLA tracking needs proper business day logic. The cost of getting it wrong—missed deadlines, SLA violations, incorrect payment dates—exceeds the cost of implementing it right.

Start with weekends. Add national holidays for your primary country. Then expand to regional holidays and additional countries as your user base grows. Each layer adds accuracy, and the API approach means you don't have to maintain the data yourself.

Calculate working days accurately with the Working Days API. Look up holidays worldwide with the World Holidays API. Get date math right the first time with the Date Calculator API.

Originally published at APIVerve Blog

Summarize Text with AI: A Practical Guide

APIVerve — Mon, 09 Mar 2026 19:07:05 +0000

Long content is everywhere. Articles run thousands of words. Customer emails ramble across paragraphs. Research papers span dozens of pages. Support tickets contain three complaints, two tangents, and buried somewhere in the middle, the actual problem.

Readers skim. Attention is limited. The information exists, but extracting it takes effort that people don't have. This is where AI summarization helps—condensing content to its essential points so readers can understand quickly and decide whether to engage further.

Extractive vs. Abstractive (and Why It Matters)

Text summarization extracts the most important information from a document and presents it in condensed form. Good summarization preserves meaning while dramatically reducing length. But not all summarization works the same way.

There are two fundamental approaches. Extractive summarization pulls key sentences directly from the original text and combines them. The summary uses the author's exact words, just fewer of them. Abstractive summarization generates new sentences that capture the meaning, potentially using different wording than the original.

Most practical summarization systems use extractive methods or hybrid approaches. Extractive summaries are more predictable—you know the output contains actual sentences from the input. Abstractive summaries can be more readable but occasionally introduce errors or hallucinations.

Here's the catch: the quality of a summary depends heavily on the input. Well-structured documents with clear topic sentences summarize better than rambling, disorganized text. A news article with a clear lead paragraph summarizes easily. A stream-of-consciousness email might not.

When Summarization Adds Value

Summarization isn't appropriate everywhere. It works best in specific contexts where readers need quick understanding without full detail.

Content previews. Article cards in a news aggregator need short descriptions. Generating these from the full article text ensures accuracy—no human needs to write descriptions for every piece.

Search results. When users search your content, showing a relevant snippet helps them decide which result to click. Summarization can generate these snippets contextually.

Email and notification digests. Daily or weekly rollups contain too many items to show in full. Summaries let recipients scan quickly and click into items that interest them.

Support ticket triage. Support dashboards show ticket lists. Agents need to scan quickly and prioritize. A two-sentence summary of each ticket beats reading every word of every complaint. This one alone can save hours per day for a busy support team.

Meeting notes. Transcript summarization pulls out key decisions and action items. Attendees can confirm accuracy without reviewing the entire recording.

Research and analysis. Researchers reading many papers benefit from summaries that help them decide which papers deserve full attention.

The common thread: situations where understanding the gist matters more than understanding every detail, and where the volume of content exceeds the available attention.

Summary Length and Quality

The relationship between summary length and quality isn't linear. Shorter isn't always better.

Very short summaries (one sentence) capture only the single most important point. They work for headlines and notifications but lose nuance. A complex article reduced to one sentence will necessarily omit important context.

Medium-length summaries (2-4 sentences) balance brevity with completeness. They can capture the main point plus supporting context. This length works for previews, digests, and triage interfaces.

Longer summaries (5+ sentences) approach executive summary territory. They preserve more detail and work for situations where readers need substantive understanding without reading the full document.

The right length depends on context. A content card might need one sentence. A support ticket summary might need three. A research paper abstract might need a full paragraph.

Most summarization APIs let you specify length—typically as a number of sentences. Experiment with your content to find the length that serves your use case.

Handling Different Content Types

Different content types summarize differently.

News articles summarize well because journalists write with summarization in mind. The lead paragraph contains the key information. The inverted pyramid structure puts important facts first. Summarization often just extracts this existing structure.

Academic papers have explicit abstracts written by the authors. Summarization adds value for papers without abstracts or for generating even shorter summaries of the abstracts.

Customer feedback tends to be less structured. Reviews ramble, combine multiple topics, and vary wildly in length. Summarization helps but may require longer summaries to capture the mix of points.

Conversational text (chat logs, meeting transcripts) is particularly challenging. Conversation meanders. Multiple speakers interleave. Important points aren't always stated explicitly. Summarization works but may miss implicit meaning.

Technical documentation summarizes reasonably well if the documentation is well-written. Step-by-step procedures condense to descriptions of what gets accomplished.

Know your content. Test summarization on representative samples before deploying it widely.

Aggregating Multiple Summaries

Sometimes you need to summarize not one document but many. Product reviews across hundreds of customers. Support tickets for the past week. Articles from multiple sources on the same topic.

The naive approach—concatenating everything and summarizing the result—fails at scale. Documents become too long, and summaries lose coherence.

Better approaches exist. Summarize each document individually, then summarize the summaries. This hierarchical approach handles arbitrary scale while maintaining quality at each level.

For aggregation to work well, you need volume. Summarizing three reviews produces a thin aggregate. Summarizing three hundred produces genuine insight: "Customers consistently praise battery life and criticize the charging cable."

Combining with Other Analysis

Summarization pairs well with other text analysis.

Sentiment analysis tells you how the content feels—positive, negative, neutral. Combined with summarization, you know both what was said and how it was said. "Customers complain about shipping delays (negative)" is more useful than either piece of information alone.

Topic extraction identifies what the content is about. Combined with summarization, you can organize summaries by topic. Support tickets become "5 tickets about billing issues, 3 about login problems."

Language detection identifies what language the content is in. For multilingual applications, you might summarize in the original language or translate before summarizing.

These combinations create richer understanding than any single analysis provides.

Implementation Considerations

The API call itself is simple:

const response = await fetch('https://api.apiverve.com/v1/textsummarizer', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    text: articleContent,
    sentences: 3
  })
});

const { data } = await response.json();
// data.summary contains the condensed text

Beyond the API call, consider caching. The same input always produces similar output (with minor variations). Cache summaries alongside their source content to avoid redundant API calls.

Consider preprocessing. Very long documents might need truncation before summarization. Documents with lots of boilerplate (legal disclaimers, repeated headers) might benefit from cleaning first.

And don't overlook user expectations. Make it clear when content is summarized rather than original. Users who don't realize they're reading a condensed version will blame you when details are missing.

Quality Assessment

How do you know if summaries are good? Manual review helps initially. Read summaries alongside their source texts. Do the summaries capture the key points? Do they miss anything important? Are they readable?

User feedback provides ongoing signal. If users consistently click through to full content after reading summaries, the summaries might not be providing enough information. If users seem satisfied with summaries alone, they're working.

A/B testing helps for specific applications. Do content previews with AI-generated summaries perform better than manually written descriptions? Measure engagement to find out.

The goal isn't perfect summarization—it's useful summarization. Did the summary help someone make a faster decision? Then it worked.

Summarize text with the Text Summarizer API. Analyze sentiment with the Sentiment Analysis API. Detect language with the Language Detection API. Build smarter content processing.

Originally published at APIVerve Blog

Add Secure Password Generation to Your App

APIVerve — Mon, 09 Mar 2026 19:06:29 +0000

Users are terrible at creating passwords. Study after study confirms it. "123456" and "password" appear in breach databases millions of times. Even when people try to be clever, they follow predictable patterns—a capital letter at the start, a number at the end, maybe an exclamation point if the form demands special characters.

The solution isn't more password rules. Users just work around them. The solution is generating secure passwords for them—or at least making strong suggestions they can accept with one click.

Why Generated Passwords Matter

When users create their own passwords, they optimize for memorability. That's the opposite of security. A memorable password is, by definition, predictable. It contains words, dates, names, patterns that humans can recall—and that attackers can guess.

Generated passwords optimize for entropy. They contain random combinations that don't exist in dictionaries, don't follow keyboard patterns, and don't relate to personal information. A 16-character randomly generated password with mixed case, numbers, and symbols has roughly 100 bits of entropy. A user-created password of the same length might have 20 bits.

That difference matters. 20 bits of entropy can be brute-forced in seconds. 100 bits would take longer than the age of the universe.

Password Managers Changed the Game

Here's the good news: users increasingly use password managers. This changes the calculus entirely. When a password manager handles storage and autofill, memorability becomes irrelevant. The user never types the password manually. They never need to remember it.

So why are most signup forms still optimized for memorization? Generated passwords make perfect sense in this world. The user clicks "generate," the password manager saves it, and authentication happens automatically from then on. The friction that used to make generated passwords impractical has largely disappeared.

Your signup flow should recognize this. Offer password generation prominently. Make it easier to accept a generated password than to create one manually. The path of least resistance should also be the path of greatest security.

Where Password Generation Fits

Not every password field needs generation, but many do. Consider adding it to:

Signup flows. This is the most impactful placement. Users creating accounts are already in decision-making mode. Offering a strong generated password right when they need one catches them at the perfect moment.

Password reset flows. Users often pick weak passwords during reset because they're frustrated and just want access restored. A generated temporary password eliminates that risk.

Admin account creation. When IT staff create accounts for new employees, generated passwords ensure consistent security. No more "Welcome123!" as every new hire's first password.

API key generation. This isn't technically a password, but the same principles apply. API keys should be long, random, and impossible to guess. Users should never create them manually.

Complexity Levels and When to Use Them

Not all passwords need maximum complexity. Different contexts call for different approaches.

Strong complexity includes uppercase, lowercase, numbers, and special characters. Use this for any password that will be stored in a password manager. The user won't type it manually, so keyboard convenience doesn't matter. This is the default for most modern applications.

Medium complexity uses letters and numbers but skips special characters. This works well for temporary passwords that users will type manually—like a password reset code they read from an email while logging in on another device. Fewer characters mean fewer typos.

Simple complexity uses only letters. This might seem weak, but a long simple password can actually be more secure than a short complex one. A 20-character lowercase password has more entropy than an 8-character mixed-case password with symbols. Some legacy systems also can't handle special characters, making simple passwords a necessity.

The key is matching complexity to context. Don't force users to type K#9mPx$2 on a mobile keyboard when correcthorsebattery would be more secure and vastly easier.

Length vs. Complexity

Security experts have debated this for years, and the consensus now favors length. Honestly, it's not even close. A longer password with less complexity beats a shorter password with more complexity every time.

The math supports this. Each additional character multiplies the search space. Adding a 17th character to a 16-character password doubles the difficulty of brute-forcing it. Adding special characters to a short password? Diminishing returns by comparison.

Modern guidance suggests 16 characters minimum for passwords that will be stored in password managers, and 12 characters minimum for passwords that might be typed manually. Below 12 characters, even maximum complexity doesn't provide adequate protection against modern cracking hardware.

The User Experience of Generation

How you present password generation matters as much as the generation itself. Users need to trust the process and understand what's happening.

Make it visible. Show the generated password clearly, not hidden behind dots. Users need to see what they're accepting. A masked password field with a "show" toggle works well.

Provide copy functionality. One-click copy to clipboard is essential. Users will paste this password into their password manager. Make that action effortless.

Explain the security. A brief message like "This password would take millions of years to crack" builds confidence. Nobody wants to accept a string that looks like keyboard vomit on faith alone. Users who understand why the weird-looking string is better will be more likely to accept it.

Allow regeneration. Some users will want to generate multiple options before choosing. Others might have superstitions about certain characters. Let them regenerate as many times as they want.

Handling Password Generation Failures

What happens when the generation API is unavailable? Your application shouldn't break. Users shouldn't be stuck.

The graceful approach is falling back to client-side generation. Modern browsers provide crypto.getRandomValues(), which produces cryptographically secure random numbers. While a client-side fallback might not offer all the same features as an API (like complexity levels or avoiding ambiguous characters), it can produce a strong password in a pinch.

Never let an API failure prevent users from completing signup. This is an enhancement, not a gate. Fail open.

Storing and Transmitting Generated Passwords

Generated passwords require the same security precautions as user-created ones. Hash before storing. Transmit over HTTPS. Never log in plaintext.

The one difference: temporary passwords for reset flows need special handling. These should expire quickly—24 hours maximum, ideally much sooner. They should also force a password change on first use. A temporary password that becomes permanent defeats the purpose.

Measuring Success

How do you know if password generation is working? Track adoption and security outcomes.

Generation rate. What percentage of new signups use generated passwords versus creating their own? If the answer is under 10%, your UX isn't compelling enough.

Reset frequency. Users with generated passwords should reset less often. If they're resetting more, something's wrong with your generation or storage flow.

Breach exposure. When credentials appear in breach databases, how many of your users are affected? Generated passwords should appear far less frequently than user-created ones.

These metrics help you tune the experience over time.

Integration Example

Here's a minimal example of generating a password via API:

const response = await fetch(
  'https://api.apiverve.com/v1/passwordgenerator?count=1&length=16&complexity=strong',
  { headers: { 'x-api-key': 'YOUR_API_KEY' } }
);

const { data } = await response.json();
const password = data.passwords[0].password;
// "K#9mPx$2vLnR@4wQ"

Present this to the user with a copy button, let them accept it, and your signup security improves immediately.

Generate secure passwords with the Password Generator API. Verify password strength with the Password Strength API. Build authentication flows that protect your users by default.

Originally published at APIVerve Blog

Generate PDFs from HTML with an API

APIVerve — Mon, 09 Mar 2026 19:05:52 +0000

At some point, every application needs to generate a PDF. It's never the exciting feature on the roadmap, but it's always there: invoices, reports, receipts, certificates. PDFs survive because they look the same everywhere—every device, every printer, every OS.

The traditional path to generating them is painful. Install libraries, manage system dependencies, learn layout APIs that have nothing to do with how you build the rest of your application. Or spin up headless browsers, which means infrastructure just to render documents.

The simpler approach: write HTML, send it to an HTML to PDF API, receive a PDF. Your existing CSS skills work. Your existing templating works. No binary dependencies to install or browser processes to manage.

You Already Know the Layout Language

HTML and CSS were designed for document layout. Before the web, they were literally specification languages for formatting printed pages. The print stylesheet (@media print) exists precisely because browsers have always known how to render documents for paper.

This makes HTML a natural fit for PDF generation. You're not learning a new layout system—you're using the one you already know. Flexbox works. Grid works. Custom fonts work. Background colors, borders, tables—all of it translates directly.

The only real shift is thinking in fixed dimensions instead of responsive ones. A PDF has a specific page size. Content needs to fit within margins. Page breaks should fall in sensible places. These constraints exist in CSS already; most developers just haven't used them.

Common PDF Use Cases

Understanding what you're generating helps you design better templates.

Invoices need to be legally compliant documents. They require specific information: seller details, buyer details, line items, totals, tax breakdowns, payment terms. The layout should be clean and professional because customers will see these. Many will file them for accounting purposes.

Reports present data with context. They often include charts, tables, and explanatory text. Reports tend to be longer than other documents and may need headers, footers, and page numbers. The audience is usually internal—executives, analysts, stakeholders reviewing information.

Receipts are transactional records. They're typically short, confirming what was purchased, when, and for how much. Some receipts need to look like traditional paper receipts (monospace font, narrow width). Others can be more designed.

Certificates are ceremonial documents. Completion certificates, awards, diplomas—these are meant to be displayed or framed. They use formal typography, borders, and careful spacing. Landscape orientation is common.

Each type has different design priorities. Invoices prioritize clarity and compliance. Reports prioritize information density. Receipts prioritize scannability. Certificates prioritize aesthetics.

Designing for Print

Web design assumes infinite vertical space and varying horizontal space. Print design assumes fixed dimensions on both axes. This shift requires a few adjustments.

Page size matters. Letter (8.5" × 11") is standard in the US. A4 (210mm × 297mm) is standard elsewhere. Your PDF needs to target a specific size, and content must fit within it. Design your templates with these constraints in mind.

Margins create breathing room. Print documents need margins—both for readability and because most printers can't print to the edge. Half-inch margins are a reasonable default. Formal documents might use one-inch margins.

Page breaks need control. A table split awkwardly between pages looks unprofessional. CSS provides page-break-before, page-break-after, and page-break-inside properties to control where breaks occur. Use page-break-inside: avoid on elements that shouldn't be split.

Colors print differently. That vibrant blue on screen might look washed out on paper. If documents will be printed frequently, test your colors on actual paper. Consider offering a "print-optimized" version with higher contrast.

Template Architecture

Separate your PDF templates from your application logic. Templates should be pure HTML with placeholder tokens that your code fills in before generation.

This separation provides several benefits. Designers can modify templates without touching application code. Templates can be version-controlled independently. The same template can generate different documents by passing different data.

A template for an invoice might have placeholders like {{customer_name}}, {{line_items}}, and {{total}}. Your code retrieves the order data, fills in the placeholders, and sends the completed HTML for PDF generation.

Keep templates simple. The moment you start putting business logic in a template, you've created a debugging nightmare. If a template needs conditional sections or loops, handle that logic before the template receives the data.

Embedding Images and Fonts

PDFs often need images—logos, signatures, charts. You have two options for embedding images in HTML that becomes a PDF.

External URLs work if the images are publicly accessible. The PDF generation service fetches them during rendering. This is simplest but requires public hosting for your images.

Base64 encoding embeds the image directly in the HTML. The image travels with the HTML, requiring no external fetch. This is more self-contained but increases the HTML payload size. For documents that need machine-readable identifiers, you can embed a generated barcode or QR code image directly into the HTML before conversion.

For logos and standard branding elements that appear on every document, base64 encoding makes sense. For dynamic content like charts or user-uploaded images, external URLs are more practical.

Custom fonts work similarly. Reference them via Google Fonts or another CDN, or embed them as base64. Standard web fonts like Arial, Georgia, and Courier are always available.

Page Layouts

Different document types call for different layouts.

Portrait orientation (tall) is the default and works for most documents. Invoices, letters, receipts, and most reports use portrait.

Landscape orientation (wide) suits documents with wide tables or horizontal content. Financial spreadsheets, Gantt charts, and certificates often work better in landscape.

Multi-column layouts can fit more content per page. Newsletters and some reports use two or three columns. CSS columns or Grid make this straightforward.

Headers and footers provide consistent information across pages. Page numbers, document titles, dates, and company logos commonly appear in headers or footers. CSS has @page rules for controlling headers and footers, though support varies.

Handling Long Content

Some documents span many pages. Reports with extensive data, contracts with many sections, or invoices with hundreds of line items all need to handle pagination gracefully.

The key is controlling where page breaks occur. You don't want a page break in the middle of a table row or between a heading and its first paragraph. CSS page break properties let you specify that certain elements should stay together.

For very long tables, consider repeating the header row on each page. This makes the document usable even when printed—readers don't have to flip back to see what each column represents.

Test your templates with maximum-length content. Honestly, this matters more than getting the styling pixel-perfect. If your invoice template works fine with 5 line items but breaks horribly with 50, you'll find out at the worst possible time.

Storage and Delivery

Generated PDFs need to go somewhere. The generation API provides a temporary download URL, but that URL expires. For documents you need to keep, download the PDF and store it in your own system.

Cloud storage (S3, Google Cloud Storage, Azure Blob Storage) is the typical choice. Store PDFs with organized paths: /invoices/2026/03/INV-001234.pdf. This makes retrieval and cleanup straightforward.

For immediate delivery (user clicks "Download Invoice"), you can stream the PDF directly from the generation API. For background generation (nightly reports, batch invoicing), generate the PDFs, store them, and email links to recipients.

Generation Example

The actual API call is minimal. Prepare your HTML, send it, receive a PDF:

const response = await fetch('https://api.apiverve.com/v1/htmltopdf', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    html: invoiceHtml,
    landscape: false,
    marginTop: 0.5,
    marginBottom: 0.5
  })
});

const { data } = await response.json();
// data.downloadURL contains the PDF

Most of the work is in preparing the HTML. The generation itself? One API call.

Performance Considerations

PDF generation isn't instant. Complex documents with many images or large tables take longer to render. Plan for this in your user experience.

For user-initiated generation (clicking a download button), show a loading indicator. Generation typically takes 1-5 seconds depending on complexity.

For bulk generation (monthly invoice runs, batch reports), process documents in parallel but respect rate limits. Consider running batch jobs during off-peak hours.

Cache generated PDFs when the underlying data won't change. An invoice for order #12345 will always contain the same information. Generate it once and serve the cached version on subsequent requests.

Generate PDFs from HTML with the HTML to PDF API. Convert Markdown with the Markdown to PDF API. Capture entire websites with the Website to PDF API. Build document workflows without the infrastructure headaches.

Originally published at APIVerve Blog

How to Detect VPN and Proxy Users

APIVerve — Mon, 09 Mar 2026 19:05:16 +0000

Should you block a user just because they're on a VPN? Probably not. But should you ignore it entirely? Also no.

VPNs create a real paradox: privacy-conscious users and fraudsters look identical at the network level. Both show up as traffic from an IP that isn't the user's real location. The question isn't whether VPN users are good or bad—it's what you do with that signal.

What VPN Detection Actually Tells You

When you detect a VPN, you learn one thing with certainty: the IP address you see isn't where the user physically sits. Everything else is inference.

This matters because IP-based assumptions underpin many security and business decisions. Geo-restrictions assume the IP reflects the user's country. Fraud scoring assumes the IP reflects the user's typical location. Abuse prevention—often paired with an IP lookup for location context—assumes the IP can identify repeat offenders.

VPN detection doesn't tell you the user is malicious. It tells you that your IP-based assumptions might be wrong. That's valuable information, but it requires nuance in how you respond.

Not All Hidden IPs Are Created Equal

Not all IP masking is equal, and treating it that way is one of the most common mistakes teams make.

Consumer VPNs are the most common. Services like NordVPN, ExpressVPN, and Surfshark provide privacy for everyday users. Someone on a consumer VPN might be protecting themselves on public WiFi, bypassing regional content restrictions, or just valuing privacy generally. Consumer VPN usage alone is a weak fraud signal.

Datacenter IPs are more concerning. When traffic comes from AWS, Google Cloud, or DigitalOcean, it's almost never a regular user browsing from their laptop. Datacenter IPs typically indicate automation—bots, scrapers, or programmatic access. A bot detector can help distinguish legitimate automation from malicious automation.

Tor exit nodes represent the strongest anonymity. Tor users have deliberately chosen a system designed to make tracing impossible. While Tor has legitimate uses (journalists in authoritarian countries, whistleblowers, privacy advocates), it's also the tool of choice for serious bad actors. Tor traffic warrants the highest scrutiny.

Residential proxies are the hardest to detect. These route traffic through real residential IP addresses, making it appear as normal consumer traffic. They're expensive and primarily used for sophisticated operations—either legitimate (price comparison, ad verification) or illegitimate (credential stuffing, sneaker bots).

If you take one thing from this section: the type of masking matters far more than the fact of masking.

The Problem with Blocking

Many developers' first instinct is to block VPN users entirely. This seems logical—if VPNs enable fraud, just prevent VPN access.

In practice, blanket blocking creates more problems than it solves. You'll block:

Privacy-conscious professionals who use corporate VPNs for work and leave them connected during personal browsing. Travelers who use VPNs for security on hotel and airport networks. Users in countries where VPNs are necessary for accessing uncensored internet. Security researchers and journalists who have legitimate reasons for anonymity.

Each blocked legitimate user is a lost customer and a support ticket. At scale, this friction compounds into significant business impact.

And here's the frustrating part: determined fraudsters will find ways around your blocks anyway. They'll use residential proxies you can't detect. They'll rotate through IPs until they find ones you haven't flagged. Blocking stops the casual abusers while the sophisticated ones—the ones causing real damage—adapt and continue.

Risk Scoring Instead of Blocking

The mature approach treats VPN detection as one signal among many. VPN usage adds points to a risk score. Other signals add more points. High-risk combinations trigger friction or review.

Consider this framework:

A new account signing up from a consumer VPN with a valid email address? Low additional risk. Might just be a privacy-conscious user.

A new account from a datacenter IP with a disposable email address? Moderate risk. The combination is suspicious even if neither signal alone would be.

A new account from a datacenter IP, disposable email, making a high-value purchase with expedited shipping to an address different from the billing address? High risk. This pattern matches known fraud behavior.

The VPN signal contributes to the assessment but doesn't determine it alone. This is the part most teams skip—building the scoring model—and it's also the part that actually works.

Geo-Restriction Enforcement

Some applications must enforce geographic restrictions. Streaming services have content licensed only for specific countries. Online gambling sites must comply with jurisdictional regulations. Financial services face different rules in different regions.

VPN detection becomes more important here because users actively try to circumvent restrictions. Someone in Germany using a US VPN to access US-only content is intentionally violating the restriction. Unlike fraud prevention, where VPN usage is an indirect signal, geo-restriction enforcement directly cares whether the stated location is real.

Even here, blanket blocking has drawbacks. A US user traveling abroad might use a VPN to access their US-based services. They're not circumventing restrictions—they're maintaining access to services they legitimately subscribe to from their home country.

The cleanest approach is transparency. Tell users that VPN access is restricted and why. Offer them the option to disable their VPN and retry. This respects their choice while maintaining compliance.

The Datacenter IP Signal

Datacenter IPs deserve special attention because they're almost never legitimate consumer traffic. Regular users browse from home connections, mobile networks, or corporate networks—not from cloud servers.

When you see traffic from a datacenter IP, you're likely seeing:

Bots and scrapers. Automated systems that collect data, test credentials, or interact with your application programmatically.

Proxy services. Some proxy services route traffic through datacenter infrastructure rather than residential IPs.

Legitimate automation. Monitoring services, integration testing, webhook deliveries. These are valid but should probably be authenticated differently than user traffic.

The response to datacenter traffic can be stricter than the response to consumer VPNs. Rate limiting is almost always appropriate. Additional authentication challenges are reasonable. For high-risk operations like account creation or purchase completion, requiring a non-datacenter IP is defensible.

Implementation Patterns

The technical implementation is straightforward. Check the user's IP against a VPN detection API on requests where you need the information—typically authentication, checkout, and account creation endpoints.

const response = await fetch(
  `https://api.apiverve.com/v1/vpndetector?ip=${clientIp}`,
  { headers: { 'x-api-key': 'YOUR_API_KEY' } }
);
const { data } = await response.json();

// data.is_vpn - boolean, is this a VPN exit node?
// data.is_datacenter - boolean, is this a cloud/hosting IP?
// data.risk_level - string, overall risk assessment

Cache results by IP address. VPN status doesn't change frequently—an hour TTL is reasonable. This reduces API calls and latency for repeat visitors.

Attach the results to the request context so downstream code can access it. Your fraud scoring, rate limiting, and access control logic can all reference the same detection data without redundant API calls.

What Not to Do

A few anti-patterns to avoid:

Don't show accusatory messages. Seriously, don't. "We detected you're using a VPN" sounds like an accusation. Users who aren't doing anything wrong will be offended. Users who are doing something wrong won't be deterred.

Don't rely solely on VPN detection for security. It's one signal. Sophisticated attackers use residential proxies, compromised consumer devices, and other techniques that evade detection.

Don't log VPN status with personally identifiable information. This creates a record that could be subpoenaed or breached. Log aggregate statistics if you need them for analysis.

Don't update your detection database infrequently. VPN providers constantly add new exit nodes. Tor exit nodes rotate regularly. Your detection needs fresh data to stay accurate.

Measuring Effectiveness

Track the impact of VPN detection on your fraud and abuse metrics. Are you catching more bad actors? Are you creating friction for legitimate users?

Monitor false positive rates by correlating VPN detection with downstream outcomes. If accounts flagged for VPN usage have the same fraud rate as unflagged accounts, your threshold might be wrong.

Compare chargebacks and abuse reports between VPN and non-VPN traffic. If VPN users have higher rates of problematic behavior, your detection is providing useful signal. If rates are similar, you might be adding friction without benefit.

Detect VPNs and proxies with the VPN Detector API. Identify Tor exit nodes with the Tor Detector API. Get complete IP intelligence with the IP Lookup API. Build smarter risk assessment.

Originally published at APIVerve Blog

Generate Barcodes for Inventory and Shipping

APIVerve — Mon, 09 Mar 2026 19:04:39 +0000

Pick up any product near you. There's a barcode on it. That pattern of black and white lines is doing more work than most features you'll build this quarter—routing packages, tracking inventory, linking physical objects to database records.

For developers building inventory systems, shipping workflows, or asset trackers, barcode generation is table stakes. When products enter your system, they need barcodes. When packages ship, tracking numbers need to become scannable labels. When equipment gets tagged, asset IDs need physical representation.

Bars, Spaces, and Why Width Matters

A barcode encodes data as a pattern of bars and spaces of varying widths. Scanners read these patterns by measuring the reflectivity of each segment—dark bars absorb light, white spaces reflect it. The sequence of measurements translates back into the original data.

Different barcode symbologies (formats) use different encoding schemes. Some encode only numbers. Some encode letters and numbers. Some can represent any data including binary. The choice of symbology depends on what you're encoding and where the barcode will be scanned.

The physical appearance matters too. Barcodes need sufficient contrast between bars and background. They need minimum sizing to be scannable at practical distances. They need quiet zones (blank space) around them so scanners know where the barcode begins and ends.

Skip any of these details and you'll end up with barcodes that look right on screen but fail the moment a scanner tries to read them.

Code 128: The Modern Standard

Code 128 is the most widely used barcode symbology for logistics and inventory. It's compact, efficient, and supports the full ASCII character set—letters, numbers, and symbols.

The compactness matters. Code 128 encodes more data per inch than older symbologies. A Code 128 barcode containing "SKU-12345678" is physically shorter than the same data in Code 39. Shorter barcodes fit on smaller labels and scan more reliably at angles.

Code 128 automatically switches between encoding modes to optimize density. Sequences of numbers encode more compactly than sequences of letters. The symbology handles this internally—you just provide the data.

For most applications—product labels, shipping labels, inventory tags—Code 128 is the right choice. It's supported by virtually every scanner and works across all industries.

Code 39: The Legacy Workhorse

Code 39 is older and less efficient than Code 128, but it remains common in certain industries. The US Department of Defense uses Code 39 for military asset tracking. Many automotive manufacturers specify Code 39 in their supply chain requirements.

Code 39 encodes uppercase letters, numbers, and a few special characters. It's self-checking, meaning a single misread bar won't produce valid-looking garbage—it will produce an invalid barcode that the scanner rejects.

The trade-off is density. Code 39 barcodes are physically wider than Code 128 for the same data. A 15-character asset ID in Code 39 might be twice as wide as Code 128.

Use Code 39 when external requirements mandate it. For new systems without legacy constraints, Code 128 is generally better.

Designing Barcode Labels

A barcode by itself is just a pattern. Useful labels combine the barcode with human-readable information.

Human-readable data appears below the barcode. This is the same data encoded in the barcode, printed as text. When scanners fail, humans can read the number and enter it manually. Include this on every label.

Contextual information surrounds the barcode. For a product label, this might include the product name, price, or size. For a shipping label, the recipient address and service level. The barcode identifies; the context explains.

Layout matters for scanning. Barcodes need quiet zones—blank space on either side. They need minimum height for reliable scanning. They need contrast with the background. A barcode crammed into a corner with no margins will cause scanning failures.

Print quality affects reliability. Thermal printers produce excellent barcodes. Inkjet printers work but require good paper. Laser printers sometimes produce barcodes with insufficient contrast. Test with real printers and real scanners before deploying—this is the step that saves you from warehouse chaos on launch day.

Inventory and SKU Labels

Inventory management systems typically assign SKU (Stock Keeping Unit) codes to products. These SKUs become barcodes on product labels.

SKU formats vary by organization. Some use sequential numbers. Some encode product attributes into the SKU structure. Some combine vendor codes with internal identifiers. Whatever your SKU format, it becomes barcode content.

The workflow looks like this: A new product enters inventory. The system assigns a SKU. The system generates a barcode encoding that SKU. The barcode prints on a label. The label attaches to the product or its storage location.

From that point on, the barcode is the bridge. Scanning a product during receiving updates quantity counts. Scanning during picking confirms the right product. Scanning during shipping records what went out. The barcode is the link between physical items and database records.

Shipping and Tracking Labels

Shipping labels present specific requirements. They're affixed to packages that travel through rough environments. They're scanned by many different parties—your warehouse, the carrier, intermediate hubs, the recipient.

Tracking numbers encode into barcodes on shipping labels. These numbers are typically assigned by carriers, though some shippers generate their own for internal tracking before carrier handoff.

The label usually includes multiple barcodes. A large barcode for the tracking number. Smaller barcodes for routing information. These redundant encodings help when packages are damaged or when different scanners have different capabilities.

Label placement affects scanning. Labels should be on flat surfaces, not wrapped around corners. They should be visible without opening or manipulating the package. Standard placement (top of package for flat items, side for boxes) helps automated scanning systems.

Asset Tracking Tags

Organizations track equipment, tools, vehicles, and other assets with barcode tags. Unlike inventory that flows in and out, assets typically stay within the organization but move between locations and users.

Asset IDs often encode more than just a number. They might include category codes, location codes, or department identifiers. An asset ID like "IT-LAP-2024-0047" encodes the department (IT), asset type (laptop), year, and sequence. This structure helps humans understand the ID even without looking it up.

Asset tags need durability. Equipment lasts years. Tags must survive handling, cleaning, and environmental conditions. Metal asset tags with engraved barcodes work for harsh environments. Laminated labels work for office equipment. Matching tag durability to asset lifecycle prevents premature tag failure.

Periodic scanning maintains asset databases. Annual inventories scan all equipment. Check-out processes scan before equipment leaves. Check-in processes scan on return. Each scan updates location and status.

Batch Generation

Many workflows need many barcodes at once. A new shipment of products needs labels for every item. A warehouse reorganization needs location labels for every bin. An IT refresh needs asset tags for every device.

Batch generation creates multiple barcodes efficiently. Rather than generating one at a time, generate all needed barcodes in a single operation. This is faster and ensures consistency—all labels from the same batch look identical.

Batch output might be individual images or a print-ready document. Individual images work when labels print separately or integrate into other documents. For print-ready output, you can combine generated barcodes with an HTML to PDF conversion to produce label sheets that print all at once.

Label sheets follow standard formats. Avery 5160 provides 30 labels per letter-sized page. Avery 5163 provides 10 larger labels. Matching your output to your label stock saves time and materials.

Integration Example

Generating a barcode through an API is straightforward:

const response = await fetch('https://api.apiverve.com/v1/barcodegenerator', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    data: 'SKU-12345678',
    type: 'code128',
    displayValue: true
  })
});

const { data } = await response.json();
// data.downloadURL contains the barcode image

The displayValue option prints the encoded data below the barcode for human readability. This is almost always what you want.

Scanner Compatibility

Not all scanners read all symbologies. Before deploying barcodes, verify that your scanners support your chosen format.

Most modern scanners support Code 128 and Code 39 without configuration. Older scanners might need symbology enabled in settings. Smartphone apps generally support common symbologies but may struggle with damaged or poorly printed barcodes.

Scanner distance matters. Handheld scanners read at arm's length. Fixed-mount scanners (like those at checkout lanes) read at specific focal distances. Larger barcodes scan from farther away. Match barcode size to scanning distance.

And again: test in realistic conditions. A barcode that scans perfectly on your desk might fail when printed on glossy label stock. A barcode that scans in good lighting might fail in a dim warehouse corner. Test where barcodes will actually be used.

Beyond Linear Barcodes

Linear barcodes (the traditional bar patterns) work well for simple identifiers but have limitations. They encode limited data. They require line-of-sight scanning—you can't scan through plastic or read a damaged bar.

QR codes and other 2D symbologies encode more data in the same space. They include error correction—partially damaged codes still scan. A QR code generator can encode URLs, contact information, or structured data.

For simple identification (SKUs, tracking numbers, asset IDs), linear barcodes remain ideal. For richer data (product URLs, configuration data, complex identifiers), consider QR codes instead.

Generate barcodes with the Barcode Generator API. Create QR codes with the QR Code Generator API. Build inventory and logistics systems that work at scale.

Originally published at APIVerve Blog

Email Validation Best Practices: Beyond Simple Regex

APIVerve — Wed, 04 Mar 2026 21:36:31 +0000

A customer types their perfectly valid email address into your signup form. Your validation rejects it. They don't contact support—they just leave. You never know it happened.

This is more common than most teams realize. Overly strict email validation quietly kills conversions while giving the false comfort that your data is "clean." Meanwhile, the truly fake addresses—typos, disposable inboxes, nonexistent domains—sail right through a basic regex check.

Getting validation right means catching the junk without blocking the real people. That balance is harder than it sounds.

The Surprisingly Permissive Email Spec

The email address specification (defined in RFC 5321 and RFC 5322) is more permissive than most people realize. Valid email addresses can include:

Dots in various positions - Both first.last@example.com and f.i.r.s.t@example.com are valid. Dots can appear almost anywhere in the local part (the part before the @).

Plus signs for sub-addressing - user+newsletter@gmail.com is valid and widely used. Gmail and other providers use the plus sign to create aliases that deliver to the main address. Many users employ this for filtering and tracking which services share their email.

Apostrophes and other special characters - o'brien@company.ie is perfectly valid. Irish names, French names, and others frequently include apostrophes. Hyphens, underscores, and various other characters are also permitted.

Numeric local parts - 12345@example.com is valid. Some organizations use numeric identifiers as email addresses.

Long top-level domains - Modern TLDs go far beyond .com and .org. Addresses like user@company.photography or contact@brand.engineering are valid and increasingly common.

International characters - The email specification now supports internationalized email addresses with non-ASCII characters. 用户@例え.jp is a valid email address format.

IP address domains - Technically, user@[192.168.1.1] is valid, though rarely used in practice.

Quoted local parts - "john doe"@example.com with spaces inside quotes is valid per the specification.

Every restriction you add to email validation potentially rejects someone's real, working email address. That's worth sitting with for a moment.

Why Simple Regex Fails

The internet is full of email validation regex patterns, ranging from simple to absurdly complex. Most of them cause problems.

Simple patterns reject valid addresses. A pattern that only allows alphanumeric characters, dots, and @ symbols will reject plus signs, apostrophes, and other valid characters. Users with these addresses can't sign up.

Complex patterns are unmaintainable. The regex needed to fully match the email specification is hundreds of characters long and virtually impossible to debug. Even then, it only validates format—not whether the address actually works.

All regex only validates format. Whether simple or complex, regex can only answer "does this string match a pattern?" It cannot answer "does this email address receive mail?" which is usually the question that actually matters.

Format validation catches obviously malformed input—missing @ symbols, empty strings, addresses that are clearly not emails. For anything beyond that, format validation alone is insufficient.

Deliverability vs. Format Validity

Understanding the difference between format validity and deliverability is crucial for email validation.

Format validity asks: Does this string conform to the email address specification? This is what regex checks.

Deliverability asks: If I send an email to this address, will it arrive? This is what usually matters.

An email address can be perfectly formatted and completely undeliverable:

Typos in the domain - user@gmial.com passes format validation. Gmail doesn't own gmial.com. The email will never arrive.

Non-existent domains - user@thisdoesnotexist12345.com looks like an email address. But if the domain doesn't exist or has no mail servers configured, no email can be delivered.

Non-existent mailboxes - randomstring8472@gmail.com has correct format and a valid domain. But if no one has registered that Gmail account, emails bounce.

Disabled or full mailboxes - The address once worked but the account was closed, or the mailbox is full and rejecting new messages.

Spam traps - Some email addresses exist specifically to catch spammers. Sending to them damages your reputation.

Format validation catches maybe 5% of email problems. Just 5%. Deliverability validation catches the rest.

A proper email validation API returns comprehensive results:

const response = await fetch(
  'https://api.apiverve.com/v1/emailvalidator?email=user@example.com',
  { headers: { 'x-api-key': 'YOUR_API_KEY' } }
);
const { data } = await response.json();

// Check deliverability, not just format
if (data.isValid && data.isMxValid && data.isSmtpValid) {
  // Email is likely deliverable
}

// data also includes:
// - isFreeEmail: true for Gmail, Yahoo, etc.
// - isCompanyEmail: true for business domains
// - hasTypo: true if domain looks like a typo (gmial.com)

This tells you not just whether the format is correct, but whether the domain has mail servers, whether those servers accept connections, and whether it's a business or free email provider.

Checking Email Deliverability

Real email validation goes beyond format checking to verify deliverability through multiple steps:

DNS lookup - Does the domain exist? Every email domain must have DNS records. If the domain doesn't resolve, no email can be delivered.

MX record check - Does the domain have mail servers configured? The MX (Mail Exchanger) records specify which servers handle email for a domain. No MX records usually means no email capability.

SMTP verification - Can you connect to the mail server? Does it accept mail for this address? Some mail servers will tell you whether a specific mailbox exists. Others refuse to answer (to prevent address enumeration attacks).

Reputation assessment - Is this domain associated with spam or fraud? Are deliverability rates historically low?

These checks require network requests and can't be done with client-side regex. They typically take 1-3 seconds per address, which is acceptable for form submission but too slow for real-time validation on every keystroke.

Disposable Email Detection

Disposable email services provide temporary addresses that expire after minutes or hours. Popular services include Guerrilla Mail, 10 Minute Mail, Temp Mail, Mailinator, and hundreds of others.

People use disposable emails for various reasons:

Avoiding spam - Signing up for services that might sell their email or send unwanted messages.

One-time access - Downloading content or accessing gated material without providing a real address.

Testing - Developers testing email flows without cluttering their real inbox.

Abuse - Creating multiple accounts to exploit free trials, accumulate referral bonuses, evade bans, or engage in fraud.

Whether to block disposable emails depends on your use case:

Trial signups - If you're offering a free trial and want a relationship with the user, blocking disposables makes sense. Users who won't provide a real email are unlikely to convert.

Newsletter signups - Blocking might cost you some legitimate subscribers who are just cautious about spam.

Account creation - For platforms where account value builds over time, requiring a permanent email address is reasonable.

One-time downloads - Blocking disposables might be unnecessary friction. The transaction is complete; you may not need ongoing communication.

Disposable email detection requires maintaining an updated database of disposable domains. New services appear constantly, so static lists quickly become outdated. API-based detection stays current.

Handling Common Typos

Beyond validation, detecting and suggesting corrections for common typos improves user experience and data quality.

The most frequently mistyped email domains include:

gmial.com instead of gmail.com
gmal.com instead of gmail.com
gnail.com instead of gmail.com
hotmial.com instead of hotmail.com
yaho.com instead of yahoo.com
outlok.com instead of outlook.com
.con instead of .com

When you detect a likely typo, showing "Did you mean gmail.com?" converts a future bounce into a successful signup. The user appreciates the help, and you get a working email address.

Typo detection should suggest, not auto-correct. Users might have legitimate addresses at unusual domains. Let them confirm the correction rather than silently changing what they typed.

Validation Timing and User Experience

When and how you validate affects user experience as much as what you validate.

Don't validate on every keystroke. Red error messages appearing while the user is still typing are distracting and frustrating. Wait until they've finished—on blur (when they click away from the field) or on form submission.

Validate asynchronously when possible. Deep validation takes time. Start the validation when the user finishes typing the email, so results are ready by the time they submit the form.

Provide specific, actionable feedback. "Invalid email" tells users nothing. "Please include an @ symbol" identifies the problem. "Did you mean gmail.com?" solves it.

Distinguish between definite problems and warnings. A missing @ symbol is definitely wrong. A new domain you can't verify might be fine—warn but allow submission.

Remember that you might be wrong. If your validation rejects o'brien@company.ie, you're the one with the bug, not the user. Build in escape hatches for edge cases.

Different Validation for Different Contexts

Not all email collection points need the same validation rigor.

Account signup requires thorough validation. You need to send activation emails, password resets, and account notifications. An invalid email breaks the entire user experience. Full deliverability checking is justified.

Checkout and transactions also warrant careful validation. Order confirmations, shipping notifications, and receipts need to reach the customer. The transaction's value justifies the validation overhead.

Newsletter subscription can use lighter validation. A bad email just means one undelivered newsletter. The cost of false rejection (losing a subscriber) may exceed the cost of false acceptance (one bounce).

Contact forms often need only basic validation. Honestly, full deliverability checking here is overkill. You're going to read and respond manually anyway. As long as the address looks plausible, you can handle problems individually.

Profile updates should validate the new address thoroughly before replacing the old one. Consider requiring confirmation of both addresses—sending a verification to the new one and a notification to the old one.

Role-Based and Group Addresses

Some email addresses are technically valid but serve different purposes than individual mailboxes:

Role addresses like info@, support@, admin@, sales@, webmaster@ go to teams or rotate among staff. They're valid for business communication but may not be ideal for individual user accounts.

Group addresses deliver to multiple recipients. Perfectly valid, but again not individual accounts.

Auto-responders reply automatically to incoming messages. Sending transactional emails to these addresses generates noise.

Whether these matter depends on context. For a B2B service, role addresses are normal and expected. For a consumer app expecting individual users, they might warrant gentle discouragement (not hard blocking).

Free vs. Business Email Providers

Email validation can distinguish between free providers (Gmail, Yahoo, Outlook, etc.) and business domains (company-specific addresses).

Free email addresses are perfectly legitimate for consumers. They're also slightly higher risk for fraud, since creating new accounts is easy.

Business email addresses suggest professional context and are slightly harder to create in bulk. For B2B applications, business emails may indicate more serious prospects.

This distinction is useful for segmentation and prioritization, not for blocking. Plenty of legitimate business users use personal email addresses, especially for initial inquiries or small businesses.

Handling Validation Failures Gracefully

When validation fails, how you communicate matters.

Be specific about the problem. "We couldn't verify this email address exists. Please check for typos." is better than "Invalid email."

Offer suggestions when possible. "Did you mean @gmail.com?" helps users fix the actual problem.

Allow override with acknowledgment. "We couldn't verify this address. If you're sure it's correct, click Continue." respects user agency while flagging potential issues.

Don't lecture or blame. "You entered an invalid email" sounds accusatory. "Please check your email address" is neutral.

Make errors visible but not alarming. Red text is traditional for errors, but a subtle color change is often sufficient. Save the bold red for critical problems.

The Business Case for Good Validation

Poor email validation has measurable costs:

Bounced emails damage sender reputation. High bounce rates lead to deliverability problems where even valid emails land in spam folders.

Invalid data pollutes your database. Fake addresses skew metrics and waste resources on campaigns that can't reach anyone.

Lost customers leave when signup fails. A user whose valid email gets rejected will often abandon rather than contact support.

Support burden increases when users can't sign up or receive emails. These tickets could be prevented by better validation.

Good validation pays for itself in cleaner data, better deliverability, fewer support tickets, and more successful user signups.

Putting It All Together

Effective email validation is layered:

First layer: Basic format check. Is there an @ symbol? Is there content on both sides? Does the domain have a dot? This catches obvious mistakes instantly with no external calls.

Second layer: Deliverability verification. Does the domain exist? Does it have mail servers? Can you reach them? This catches typos, fake domains, and non-functional addresses.

Third layer: Quality assessment. Is it disposable? Is it a role address? Is it from a free provider? This provides context for how to treat the address.

Fourth layer: User experience. Can you suggest corrections? Can you explain problems clearly? Can you allow edge cases while flagging concerns?

Each layer builds on the previous. Skip a layer, and you miss a category of problems. Implement all layers thoughtfully, and you get clean data without frustrating legitimate users.

Validate email addresses comprehensively with the Email Validator API. Detect disposable addresses with the Disposable Email Checker API. Build signup flows that capture real email addresses without rejecting real customers.

Originally published at APIVerve Blog

API Rate Limiting Done Right: A Complete Guide

APIVerve — Wed, 04 Mar 2026 21:35:55 +0000

Your rate limiter is probably making developers hate your API. Not because rate limiting is wrong—every API needs it—but because most implementations are hostile by default.

A misbehaving client can overwhelm your servers. A bug in consumer code can accidentally DDoS you. Bad actors will abuse anything unprotected. So you add rate limiting. And then developers integrating your API hit walls they didn't expect, get blocked for behavior they thought was reasonable, and have no idea when they'll be unblocked.

The fix isn't removing limits. It's making them transparent.

Five Problems You're Solving at Once

Rate limiting serves multiple purposes, and understanding all of them prevents you from optimizing for just one:

Service protection - APIs have finite resources. Without limits, a single client making millions of requests could consume capacity needed by all other clients. Rate limiting ensures fair resource distribution.

Cost management - API operations have costs: compute, database queries, third-party service calls, bandwidth. Unlimited usage from any single client creates unpredictable costs.

Abuse prevention - Bad actors use APIs for credential stuffing, scraping, spam, and other attacks. Rate limiting restricts the damage they can do.

Quality of service - Stable response times require controlled load. Rate limiting prevents traffic spikes that degrade performance for everyone.

Business model support - Many APIs differentiate pricing tiers by rate limits. Higher limits at higher prices creates a revenue model.

These are all valid reasons to implement rate limiting. The challenge is implementing it in ways that achieve these goals without unnecessarily frustrating legitimate users.

Where Rate Limiting Goes Wrong

Common rate limiting problems frustrate developers:

Bursts trigger limits unexpectedly. A developer makes 10 requests quickly—well under their per-minute limit—but gets blocked. The rate limiter treats short bursts as attacks, even though bursts are normal behavior (page loads, batch operations, testing).

Limits aren't communicated clearly. Documentation says "1000 requests per hour" but doesn't explain how that's measured, when counters reset, or how different endpoints might have different limits.

Error messages provide no guidance. Getting "Rate limit exceeded" with no additional context leaves developers guessing. How long should they wait? Which requests counted? How close were they?

Recovery is unclear. After hitting a limit, when does normal service resume? Does waiting one second help? One minute? One hour?

Legitimate use patterns get punished. A developer following the rules—staying under stated limits—still gets blocked because their request pattern doesn't match what the rate limiter expects.

Sound familiar? These all stem from the same root cause: rate limiting designed entirely from the infrastructure perspective, without ever asking how developers actually use APIs.

Bursts vs. Sustained Rate

The most important distinction in rate limiting is between burst rate and sustained rate.

Sustained rate measures requests over longer periods—per minute, per hour, per day. This is what most documentation describes.

Burst rate measures requests in short windows—per second, per few seconds. This catches sudden traffic spikes.

Problems arise when rate limiters handle these poorly:

A simple counter that resets every minute allows exactly 100 requests per minute. But it doesn't distinguish between 100 requests spread evenly over 60 seconds and 100 requests in the first second. The second pattern might still overwhelm backend systems.

Conversely, strict per-second limiting prevents any bursting. A developer can't make 5 rapid requests even if they're making only 20 requests per minute total.

Good rate limiting uses algorithms that handle both concerns:

Token bucket algorithms allow bursts up to a limit while enforcing sustained rates. Developers can make 10 quick requests (spending accumulated tokens) but can't sustain high rates indefinitely.

Sliding window algorithms smooth out the boundary problems of fixed windows. Requests are counted across rolling time periods rather than resetting at arbitrary boundaries.

These approaches let developers work the way they naturally would—bursts and all—while still protecting your infrastructure.

Communicating Limits Clearly

Rate limit communication should happen everywhere, not just when limits are exceeded.

Documentation should be specific. State the exact limits for different tiers, different endpoints, and different operations — the way we lay it out in our own rate limits documentation. Explain how limits are measured (sliding window? fixed window?), when they reset, and how different API calls count.

Response headers should show current state. Every API response should include rate limit information:

Current limit
Remaining requests in current window
When the window resets
(Optionally) current usage count

These headers let developers monitor their consumption in real-time. They can implement their own throttling before hitting limits.

Error responses should be actionable. When rate limits are exceeded, the error should specify:

Which limit was exceeded
The limit value
How long until the limit resets
How many requests were over the limit

Dashboards should provide visibility. If your API has a developer portal, show rate limit usage graphically. Historical usage patterns help developers understand their consumption and plan capacity.

The HTTP 429 Response

HTTP defines status code 429 (Too Many Requests) specifically for rate limiting. Using it correctly helps clients handle rate limits automatically.

Key elements of a proper 429 response:

The Retry-After header specifies how long clients should wait before retrying. Many HTTP libraries automatically honor this header, backing off appropriately.

A clear error body explains what happened in human-readable terms while also providing machine-readable details (error codes, limit values, reset times).

// Good rate limit handling in your client code
async function callAPIWithRetry(url, options) {
  const response = await fetch(url, options);

  if (response.status === 429) {
    const retryAfter = response.headers.get('Retry-After');
    const waitMs = parseInt(retryAfter) * 1000 || 60000;

    await new Promise(resolve => setTimeout(resolve, waitMs));
    return callAPIWithRetry(url, options); // Retry after waiting
  }

  return response.json();
}

This pattern respects the Retry-After header that well-designed APIs include with 429 responses.

Consistent format matches your other error responses. Rate limit errors shouldn't look completely different from validation errors or server errors.

Clients that receive well-formed 429 responses with Retry-After headers can implement automatic backoff. Clients that receive cryptic errors have to guess, often getting it wrong.

Differentiated Limits

Not all API operations cost the same. A simple read from cache consumes fewer resources than a complex query across multiple databases.

Tiered limits by operation type make sense:

Read operations might have higher limits
Write operations might have lower limits
Complex search or aggregation operations might have the lowest limits
Batch operations might count differently than single operations

Per-endpoint limits allow fine-grained control. A search endpoint that's expensive to serve can have stricter limits than a simple lookup endpoint.

Per-method limits might restrict POST/PUT/DELETE operations more than GET operations.

Document these differences clearly. Developers should know that the search endpoint has a 10 requests/second limit even if the general limit is 100 requests/second.

Client Identification

Rate limiting requires identifying clients. How you identify them affects fairness and accuracy.

API key identification is most common. Each API key has its own limits. This is fair—each customer gets their allocation—but requires authentication for all requests.

IP address identification works without authentication but has problems. Multiple users behind a single IP (corporate networks, universities, NAT) share limits unfairly. Mobile users might share IPs with thousands of others.

User account identification works when your API has user login. Each user gets their own limits regardless of IP.

Combination approaches use API key when available, falling back to IP for unauthenticated requests (with stricter limits for unauthenticated access).

The identification method should match your authentication model and avoid punishing legitimate users for network topology they don't control.

Gradual Degradation

Hard cutoffs are jarring. One request succeeds; the next fails completely. Consider intermediate states:

Warning headers can signal approaching limits before they're exceeded. A header indicating "80% of limit consumed" gives developers time to adjust.

Deprioritization can slow responses rather than block them entirely. When a client exceeds soft limits, add slight delays to their requests rather than rejecting them.

Graceful reduction can limit functionality progressively. Allow read operations when write limits are exceeded. Allow cached responses when fresh data limits are exceeded.

These approaches require more sophisticated implementation but create better developer experience. The cliff edge of rate limiting becomes a slope.

Helping Developers Stay Within Limits

The best rate limiting helps developers succeed rather than just punishing failure.

Client libraries should handle limits automatically. If you provide SDKs, they should read rate limit headers and throttle requests appropriately.

Documentation should include best practices. Explain how to make efficient API calls, when to use batch endpoints, how to cache responses, and how to implement backoff.

Sandbox environments should have generous limits. Developers building and testing integrations need room to experiment without production limits.

Alerting should be available. Let developers set up notifications when they approach limits, so they can investigate before getting blocked.

Upgrade paths should be clear. When developers need higher limits, make it obvious how to get them—higher tiers, enterprise plans, special arrangements.

Handling Abuse Without Punishing Legitimate Users

Rate limiting for abuse prevention differs from rate limiting for fair usage.

Abuse patterns include:

Credential stuffing (many login attempts)
Scraping (systematic data extraction)
Spam (bulk creation of content)
Attack probing (testing for vulnerabilities)

Legitimate high-volume patterns include:

Batch processing
Data migration
Periodic synchronization
High-traffic production applications

The challenge is distinguishing between them. Both might make many requests. The difference often lies in patterns:

Are requests distributed over time or concentrated?
Do they follow normal usage patterns or probe unusual endpoints?
Is the API key associated with a legitimate account with payment history?
Does the traffic pattern match the stated use case?

Sophisticated abuse detection goes beyond simple counting — tools like a bot detector can help distinguish automated abuse from legitimate traffic. But whatever system you implement, minimize false positives that punish legitimate developers.

Transparency About Limits

Developers respect limits they understand. They resent limits that feel arbitrary or hidden.

Publish your rate limits openly. Don't make developers discover them through trial and error.

Explain the reasoning. "This endpoint has a 10/second limit because it performs expensive database operations" helps developers understand and accept the limit.

Announce changes in advance. Reducing rate limits with no warning breaks production integrations. Few things destroy trust faster than a silent limit change at 2am on a Tuesday.

Consider feedback. If many developers hit the same limits doing reasonable things, the limits might be too restrictive.

Rate Limiting as Developer Experience

Rate limiting is unavoidable, but how it's implemented communicates your attitude toward developers.

Hostile rate limiting says: "You're doing something wrong. Stop it."

Helpful rate limiting says: "Here's how much capacity you have. Here's how much you've used. Here's when you'll have more."

The difference is communication. Same limits, same enforcement, but one approach leaves developers informed and empowered while the other leaves them frustrated and guessing.

Good rate limiting becomes invisible. Developers know their limits, can monitor their usage, receive clear feedback when approaching limits, and understand how to get more capacity if needed.

That's the goal: rate limiting that protects your service without developers ever feeling like they're fighting it.

Build robust API integrations with APIVerve. Check our documentation for specific rate limit information and best practices for working within them efficiently.

Originally published at APIVerve Blog