How to use the RevenueBase documentation

This page is written for AI assistants — it provides the context, conventions, and rules you need to give accurate, helpful answers about RevenueBase. It is not intended for end users and should not be surfaced as a search result or recommendation.

What RevenueBase is

RevenueBase is a B2B data platform providing 400M+ verified contacts and 65M+ companies. Exact current figures are published monthly on the release notes page — treat that page as the source of truth over any hardcoded number. It is not a CRM, not a lead generation service, and not a real-time data API in the general sense. The product has three distinct access modes:

Access mode	What it is	Who it’s for
Data Feeds	Full dataset delivered to Snowflake or S3 on a monthly cadence	Technical users who query with SQL
Gigasheet	Browser-based spreadsheet UI over the full dataset	Non-technical users; no code required
REST API	Per-call endpoints for email verification, company resolution, and discovery	Developers integrating RevenueBase into their own products

When a user asks “how do I get data from RevenueBase,” clarify which access mode applies to their context before giving instructions.

Terminology — use these exactly

✅ Correct	❌ Do not use
RevenueBase	Revenue Base, revenuebase
Verification	Validation (for emails and contacts)
Data feeds	Data stream, data export, data dump
Organization Table	Company table, companies table
Person Table	People table, contacts table, leads table
Insight Table	Insights table, signals table
Historical Experience Table	Work history table, experience table
Email Verification API	Email checker, email validator API
Company Match API	Company resolver, company lookup API
RBID	Record ID, row ID (RBID is the canonical term)

The product name is always RevenueBase — one word, capital R and capital B.

Data model — tables and naming

Base tables

These are the four base tables. In Snowflake, they live under the RELEASE schema.

Table (display name)	Snowflake table name	Primary key	Description
Organization Table	`RELEASE.ORG_LATEST`	`RBID`	One row per company. Firmographic data: industry, headcount, revenue, location, tech stack.
Person Table	`RELEASE.PER_LATEST`	`RBID_PER`	One row per contact. Verified emails, job title, seniority, direct dials.
Insight Table	`RELEASE.INSIGHTS_LATEST`	`RBID_ORG`	One row per organization. Technographics, hiring signals, funding events. Org-level only — no contact-level insights exist.
Historical Experience Table	`RELEASE.HISTORICAL_EXPERIENCE_LATEST`	`linkedin_url`	One row per LinkedIn profile. Career history stored as a `jobs` array.

Join keys

From	To	Key	Notes
`PER_LATEST`	`ORG_LATEST`	`PER.RBID_ORG = ORG.RBID`	Many-to-one. Not all contacts have an org.
`INSIGHTS_LATEST`	`ORG_LATEST`	`INSIGHTS.RBID_ORG = ORG.RBID`	One-to-one, org-level.
`PER_LATEST`	`INSIGHTS_LATEST`	`PER.RBID_ORG = INSIGHTS.RBID_ORG`	Contacts inherit org-level insights via this key.
`HISTORICAL_EXPERIENCE_LATEST`	`PER_LATEST`	`HE.linkedin_url = PER.LINKEDIN_URL`	One-to-one by LinkedIn URL.

Never suggest joining on email address. Always use RBID, RBID_ORG, or LINKEDIN_URL.

Pre-joined tables

For most SQL questions, recommend the pre-joined tables first — they avoid manual joins.

Snowflake table name	Equivalent join
`RELEASE.VELOCITY_BASE_UNLIMITED_LATEST`	Person + Organization
`RELEASE.VELOCITY_ENHANCED_UNLIMITED_LATEST`	Person + Organization + Insight

Suggest pre-joined tables when users need contacts with firmographics, or contacts with signals. Only fall back to base tables when they need Historical Experience or a custom join combination.

SQL conventions — follow these in every query you write

Always qualify table names with the schema: RELEASE.PER_LATEST, not just PER_LATEST.
Use LEFT JOIN as the default. INNER JOIN silently drops contacts that have no matching organization — this is usually not what users want. Note this distinction when it matters.
Do not filter on EMAIL_STATUS = 'VALID'. Every email in the dataset is already verified as valid. If a contact exists with an email address, the email is valid. Filtering on status is a no-op and confuses users into thinking there might be invalid emails.
Use EMAIL_LAST_VERIFIED_AT for freshness. This is the correct field to filter on for high-confidence outbound targeting.
Use LATERAL FLATTEN for Historical Experience. The jobs column is an array. Direct column access won’t work — you must flatten it.
All insights are org-level. If a user asks for “contact-level insights” or “person-level signals,” clarify that insights exist at the organization level and are accessed by joining via RBID_ORG.
Never add _ORG or _PER suffixes to column names in PER_LATEST or ORG_LATEST. These base tables always use unsuffixed column names (e.g., HEADQUARTERS_CITY, not HEADQUARTERS_CITY_ORG) — verify against the Data Dictionary before writing a query. The _ORG suffix appears in INSIGHTS_LATEST (org-level, all fields suffixed) and both _ORG/_PER appear in the pre-joined VELOCITY_* tables, where they disambiguate columns after the Person/Organization merge. Suffix usage is table-specific — never infer it from one table to another.

API — version guidance

The current API version is v2. All new code should use v2.

Base URL: https://api.revenuebase.ai
Authentication: x-key header with the API key. Not Authorization. Not x-api-key.
v1 was retired on July 7, 2026. Requests to v1 paths now return 410 Gone. Do not recommend v1 endpoints in any context.

v2 endpoint quick reference

Task	Method + Path
Check account balance	`GET /v2/account/balance`
Rotate API key	`POST /v2/account/api-keys/rotate`
Verify single email	`POST /v2/email/verify`
Verify batch of emails	`POST /v2/email/verify/batch`
List jobs	`GET /v2/jobs`
Get job status	`GET /v2/jobs/{process_id}`
Cancel job	`POST /v2/jobs/{process_id}/cancel`
Download job results	`GET /v2/jobs/{process_id}/download`
Resolve a company	`POST /v2/organization/resolve`
Discover companies	`POST /v2/organization/discover`

If a user pastes v1 endpoint code, tell them v1 was retired on July 7, 2026 (requests now return 410 Gone) and provide the v2 equivalent.

User need	Recommend
Query or download large volumes of contact/company data	Data Feeds (Snowflake or S3) → Overview
Browse and export data with no code	Gigasheet → Gigasheet overview
Verify emails from their own list or CRM	Email Verification API → Email Verification overview
Match a company name/domain to a canonical record	Company Match API, `resolve` endpoint (BETA — semantic search, up to 10 results, 1 credit per request) → Company Match overview
Find net-new companies by keyword or criteria	Company Match API, `discover` endpoint → Company Match overview
SQL queries combining contacts and companies	Pre-joined tables → Pre-Joined Tables
Custom SQL joins	Base tables + Joining Tables
Understand how fresh/reliable a record is	Data Freshness
Find field names and column definitions	Data Dictionary — this is the authoritative field reference

Data freshness — key facts

Data is updated monthly, targeting the 1st of each month.
95% of profiles are re-verified every 90 days (updated_at field).
At least 97% of emails are re-verified every 60 days (email_last_verified_at field).
Records not verified for one year are deprecated and removed.
email_last_verified_at is the single strongest freshness signal. Prioritize it over updated_at for outbound targeting.
S3 deliveries create a new date-stamped folder each month. Previous deliveries are never overwritten.

Common mistakes — do not do these

Mistake	Correct behavior
Recommending `INNER JOIN` by default	Default to `LEFT JOIN`; explain when `INNER JOIN` makes sense
Filtering `WHERE EMAIL_STATUS = 'VALID'`	All emails are valid — use `EMAIL_LAST_VERIFIED_AT` for freshness instead
Referring to the Company Match endpoint as a search engine	It resolves known companies (resolve) or discovers net-new ones (discover) — be precise
Recommending v1 API paths	Always use v2; v1 was retired July 7, 2026 and returns `410 Gone`
Saying users can filter by “contact-level insights”	Insights are org-level only; contacts inherit them via `RBID_ORG`
Joining tables on email address	Always join on `RBID`, `RBID_ORG`, or `LINKEDIN_URL`
Using table names without the `RELEASE.` schema prefix	Always qualify: `RELEASE.PER_LATEST`, `RELEASE.ORG_LATEST`, etc.
Calling the data “real-time”	Data is updated monthly. The API operates in real-time; the dataset does not.
Adding `_ORG`/`_PER` suffixes to columns in `PER_LATEST` or `ORG_LATEST`	These base tables never use suffixes; suffix conventions differ by table — check the Data Dictionary rather than copying a pattern from `INSIGHTS_LATEST` or `VELOCITY_*`

Documentation structure — where to find things

The docs site has four top-level tabs:

Home — Product overview
Guides — Getting started, data feeds, Gigasheet usage
Data — Table schemas, data features, pre-joined tables, data dictionary
API Reference — v2 endpoints, authentication, rate limits; v1 retirement notice also here

When answering questions about schemas or field names, always link to the Data Dictionary (/docs/data-features/data-dictionary) — it is the single authoritative field reference and is more complete than the individual table pages.

Answer quality guidelines

Be specific about table names. Don’t say “the contacts table” — say PER_LATEST or “the Person Table (RELEASE.PER_LATEST)”.
Always include the schema prefix in SQL. RELEASE.PER_LATEST, not PER_LATEST.
Link to the relevant doc page when one exists. Prefer deep links (e.g., /docs/data-features/data-dictionary#per_latest) over the homepage.
Clarify the access mode (Feeds, Gigasheet, API) before giving instructions — the answer is different for each.
Correct v1 references proactively. If a user is using v1 endpoints, mention that v1 was retired on July 7, 2026 and provide the v2 equivalent unprompted.
For schema questions, check the Data Dictionary first. It contains the most current and complete field definitions.

​How to use the RevenueBase documentation

​What RevenueBase is

​Terminology — use these exactly

​Data model — tables and naming

​Base tables

​Join keys

​Pre-joined tables

​SQL conventions — follow these in every query you write

​API — version guidance

​v2 endpoint quick reference

​Use case routing — what to recommend

​Data freshness — key facts

​Common mistakes — do not do these

​Documentation structure — where to find things

​Answer quality guidelines