Skip to main content

​
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

​
Integration paths

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

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 (send it together with Order.WebsiteAnalysis and Order.NaicsPrediction), 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