Guides
API Reference

Online Presence: Basics

An introduction to Baselayer's Online Presence products, and how to choose the right integration path for your workflow.

Online Presence: Overview

Baselayer's Online Presence products give you digital-footprint intelligence on any business: whether its website is real and active, what industry it operates in, where it shows up on social media, what customers say about it, and whether it appears across online directories.

Traditional KYB confirms that a business is registered with a state agency. Online presence confirms that it actually operates as claimed — a critical second layer for fraud detection, sole proprietor verification, and any applicant where Secretary of State data is thin, missing, or inconclusive.

These signals are a cornerstone of modern business verification, particularly for businesses with thin registration data, no credit history, or operating as sole proprietors.

A note on terminology

Each sub-product is requested via an Order.* option value (e.g., Order.WebsiteAnalysis, Order.SocialMedia). An Order is both the unit of requesting a sub-product and the unit of billing — every Order is priced independently, regardless of which endpoint it was requested through.

What's included

Sub-productWhat it tells you
Website AnalysisDomain legitimacy, age, SSL validity, email deliverability, and contact discovery
Industry PredictionNAICS, MCC, and SIC codes + confidence score + extracted keywords describing core business activity + card network risk indicators
Social ProfilesDiscovered and verified social media presence across major platforms
ReviewsRatings, volume, and sentiment from Google, Yelp, Trustpilot, and others
Directory ListingsBusiness presence across online directories

Integration paths

PathWhat it does
options on POST /searchesBundles online presence into your KYB call. Returns orderable data alongside the business search result in a single response.
POST /web_presence_requestsRuns online presence independently of KYB. Full access to all sub-products, including social profiles, reviews, and directory listings.
POST /naics_prediction_requestsRuns industry classification only. A lighter, cheaper call when NAICS, MCC, and SIC codes are the only signals you need — useful for analytics, MCC validation, or pre-screening at scale.

Recommended architecture

Run KYB and online presence as separate calls.

Use POST /searches without options for business verification. Use POST /web_presence_requests for digital intelligence. This separation ensures that online presence data is returned for every applicant, including sole proprietors and businesses that don't match a registration record. When /searches returns state: FAILED, no orderables fire, even when options were included in the request.

This is the architecture that gives you 100% coverage across your applicant base. For the full sole proprietor workflow, see Sole Proprietorship Verification.

When /web_presence_requests is the better default

ScenarioWhy standalone fits
You approve sole proprietorsBundled path returns FAILED for most sole props (no SoS match means no orderables fire); standalone returns data on every applicant.
You want signals on every application, including rejected onesIndustry classification and online activity are valuable for analytics and underwriting calibration even when KYB fails.
You're latency-sensitive on KYBRunning online presence in parallel to (or earlier than) your KYB call keeps Business Search fast.
You want to pre-screen before KYBRun digital discovery early in your funnel to gather context before committing to a full KYB search.
You want fully independent pipelinesOnline presence signals never influence KYB ratings; the two run on separate tracks.

See The Web Presence API for the full decision guide and request/response details.

When bundling into /searches makes sense

Requesting options on POST /searches is a reasonable choice when:

  • Your team wants a single API call and results will primarily be reviewed in the Baselayer console rather than parsed programmatically.
  • Your applicant base consists almost entirely of registered businesses, and sole proprietors are a negligible edge case.
  • You're in an early integration phase and want to minimize the number of endpoints in your initial build.

If you use this path, follow up with POST /web_presence_requests or POST /naics_prediction_requests for any application that returned no match, to maintain full coverage.

Response shape differs by path

The underlying field structures are identical across all paths: a website_analysis object looks the same regardless of how you requested it. What changes is where the data sits in the response, and which options values are available on each endpoint.

To receive social profiles and reviews on POST /searches, you must request Order.Enhanced, there is no granular Order.SocialMedia or Order.ReviewSummary on this endpoint. Order.Enhanced covers the full bundle: Website Analysis, Industry Prediction, Social Profiles, and Reviews.

On /web_presence_requests, each sub-product can be requested individually via its own Order.* value.

Once returned, social profiles and reviews live at business.social_profiles[] and business.reviews[] on /searches, and at found_social_profiles[] and found_reviews[] on /web_presence_requests. Directory listings are only available via /web_presence_requests. Discovered addresses and officers merge into the business object on /searches (via Order.Enhanced); on /web_presence_requests, they are nested inside each sub-product object.

Response Reference → documents all placements side-by-side.

Pricing

Every Order is billed independently, as defined in your Master Service Agreement. The integration path you use does not affect cost, each Order is priced the same regardless of whether it was requested via /searches, /web_presence_requests, or /naics_prediction_requests.

Where to go next