Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.revenuebase.ai/llms.txt

Use this file to discover all available pages before exploring further.

RevenueBase continuously verifies and refreshes its dataset, but no B2B data source is perfect. This page explains how the refresh cycle works, why some records may lag, and how you can use the fields to assess quality in your own systems.

Business contacts

388M

Companies

64.9M

Business emails

65M

Mobile numbers

52.8M

​
How to read our data quality stats

  • Email re-verification: % of emails verified (last 60 days)
  • Contact freshness: % of job experiences verified on LinkedIn (last 90 days)
  • Company accuracy: % of company data verified by trusted sources (last 90 days)

​
Data updates & refresh schedule

RevenueBase data is updated on a monthly basis.

Release schedule

New data drops target the 1st of each month. Depending on weekends, the actual date may shift by ±2–3 days.

Email notifications

We send an email notification to your team when new data has been posted and is ready for consumption.

Profile verification

95% of profiles are re-verified every 90 days. “Re-verified” means the source profile was accessible and we confirmed or updated at least the core profile information — name, current title, company association, and location. Check the updated_at field for the most recent verification date on any record.

Email verification

All email addresses are re-verified every 60 days. See the email_last_verified_at field. A recently validated email is one of the strongest indicators that a record is current — prioritize records with recent email_last_verified_at dates when building high-confidence segments for outbound or enrichment.
For S3 deliveries, each update creates a new date-stamped folder. Previous deliveries remain accessible and are never overwritten. Bucket names and credentials remain the same across all deliveries.

​
How verification works

A record is “re-verified” when the source profile was accessible and we confirmed or updated core profile information — name and location, plus other core fields when available. This is distinct from simply checking that a URL resolves. Verification means we read the profile content and either confirmed it matches our existing record or updated our record to reflect changes. Two verification cycles run in parallel: Profile verification — 95% of all profiles are re-verified every 90 days. The updated_at field on each record reflects when this last occurred. It indicates core profile verification, not guaranteed refresh of every section. Work experience can be hidden by source platforms and may not refresh in a given cycle. If a profile’s updated_at is more than 90 days old, it typically means the source was temporarily inaccessible during the most recent verification cycle (see why records become stale below). Email verification — at least 97% are re-verified every 60 days, independent of profile verification. The email_last_verified_at field reflects when this last occurred. Email verification checks deliverability — whether the address accepts mail — not just whether it has valid syntax. The charts below pull from live data in our system.
A recently verified email is one of the strongest signals that a record is current. If email_last_verified_at is recent and the email status is valid, the associated work experience is very likely still accurate — even if updated_at is slightly older. Prioritize records with recently validated emails when building high-confidence segments.

​
Why records become stale

Most records in RevenueBase are verified within the cycles described above. When a record falls behind, it’s typically for one of three reasons:

​
Source accessibility issues

Profiles may return 404 errors, timeout, or become temporarily unreachable during a verification pass. When this happens, the existing record is retained but updated_at is not advanced. If a profile remains inaccessible for one year, we deprecate and remove it from the dataset entirely. This prevents the accumulation of records that can no longer be confirmed.

​
Platform scraping protections

LinkedIn and other source platforms periodically apply protections that hide full profiles — or specific sections like work experience — from public view. These protections affect random profiles and can last anywhere from days to months before the profile becomes fully accessible again. During this time, we retain the existing record but cannot update it. There is no way to predict which profiles will be affected or for how long.

​
Delayed profile updates by individuals

People frequently change jobs weeks or months before updating their online profiles. Someone who starts a new role in May might not update their LinkedIn until September. RevenueBase would then capture that change in the October or November verification cycle. This is an inherent limitation of any data source that relies on self-reported professional information — the data is only as current as the person’s last profile edit.

​
Profile deprecation

Records that have not been successfully verified for one year are deprecated and removed from the dataset. This is an intentional quality measure — it prevents your systems from relying on records that can no longer be confirmed against any source. When a profile is deprecated:
  • It is removed from subsequent monthly data releases
  • If you’re consuming via Snowflake, the record will no longer appear in *_LATEST views
  • If you’re consuming via S3, the record will be absent from the next delivery folder
  • Previous deliveries are never modified — historical snapshots remain intact

​
Assessing record quality

Every record ships with fields that let you evaluate freshness and reliability programmatically. Use these to build scoring logic, filter thresholds, or quality gates in your pipelines.
FieldWhat it tells youQuality signal
updated_atWhen core profile information was last verified against the source (name, location, and other core fields when available)Records verified within 90 days are within normal cycle. This does not guarantee every section (such as experience) was refreshed. Older records may have accessibility issues.
email_last_verified_atWhen the email address was last checked for deliverabilityRecent email verification (within 60 days) is a strong indicator the record is current.
revenuebase_contact_verification_summaryMachine-readable summary of verification status across all contact fieldsUse this for programmatic quality filtering. See Verification Summaries for schema details.
For high-confidence outbound (email campaigns, direct outreach): filter to records where email_last_verified_at is within the last 60 days. All emails in the dataset are verified as valid. 
-- High-confidence outbound: recently verified emails (all emails in dataset are valid)
SELECT *
FROM RELEASE.PER_LATEST
WHERE EMAIL_LAST_VERIFIED_AT >= DATEADD(day, -60, CURRENT_DATE());
For enrichment and analytics (market sizing, account scoring): the full dataset is appropriate, but weight records by recency — updated_at within 90 days should receive higher confidence than older records. 
-- Enrichment/analytics: weight by profile freshness (higher confidence for recent verification)
SELECT *,
       CASE
         WHEN UPDATED_AT >= DATEADD(day, -90, CURRENT_DATE()) THEN 1.0
         WHEN UPDATED_AT >= DATEADD(day, -180, CURRENT_DATE()) THEN 0.7
         ELSE 0.5
       END AS freshness_score
FROM RELEASE.PER_LATEST
ORDER BY UPDATED_AT DESC;
For AI agent pipelines: pass the revenuebase_contact_verification_summary and email_last_verified_at fields to your agent so it can make programmatic decisions about whether to act on a record or flag it for review. 
-- AI agent pipelines: include verification context for programmatic quality decisions
SELECT
  RBID_PER,
  EMAIL_ADDRESS,
  EMAIL_LAST_VERIFIED_AT,
  REVENUEBASE_CONTACT_VERIFICATION_SUMMARY,
  UPDATED_AT
FROM RELEASE.PER_LATEST
WHERE EMAIL_LAST_VERIFIED_AT IS NOT NULL;

​
Sparse profiles and data quality

Some profiles in the dataset contain minimal information — a name and company association, but limited detail on title, location, or experience. These profiles are sourced the same way as complete ones, but the underlying source simply contains less data. In some cases, sparse profiles may be incomplete or low-quality. The strongest indicator that a person genuinely belongs to an organization is a valid company email address. If a profile is sparse but has a verified email at the company domain, the association is reliable. If a sparse profile has no verified email, treat the association with lower confidence. When building segments or powering outbound, all emails in the dataset are verified as valid. Use EMAIL_LAST_VERIFIED_AT to prioritize recently verified addresses for the highest confidence.

​
Gigasheet updates

RevenueBase data in Gigasheet is refreshed automatically at the beginning of every month — no action is required on your part.
  • Any saved views you have created will be dynamically updated at the time of the data refresh. Your filters and logic are preserved; only the underlying data changes.
  • If you are receiving a raw data feed (S3, Snowflake, etc.), the updated data is delivered to your configured destination at the beginning of the month.