> ## 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. # AI Assistant Guide > Instructions for AI assistants using the RevenueBase documentation via MCP or direct retrieval. Not intended for end users. # 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](/docs/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 1. **Always qualify table names with the schema:** `RELEASE.PER_LATEST`, not just `PER_LATEST`. 2. **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. 3. **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. 4. **Use `EMAIL_LAST_VERIFIED_AT` for freshness.** This is the correct field to filter on for high-confidence outbound targeting. 5. **Use `LATERAL FLATTEN` for Historical Experience.** The `jobs` column is an array. Direct column access won't work — you must flatten it. 6. **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`. 7. **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. *** ## Use case routing — what to recommend | User need | Recommend | | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Query or download large volumes of contact/company data | Data Feeds (Snowflake or S3) → [Overview](/docs/getting-started/overview) | | Browse and export data with no code | Gigasheet → [Gigasheet overview](/docs/gigasheet/overview) | | Verify emails from their own list or CRM | Email Verification API → [Email Verification overview](/api-reference/v2/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](/api-reference/v2/company-match-overview) | | Find net-new companies by keyword or criteria | Company Match API, `discover` endpoint → [Company Match overview](/api-reference/v2/company-match-overview) | | SQL queries combining contacts and companies | Pre-joined tables → [Pre-Joined Tables](/docs/data-features/pre-joined-tables/pre-joined-overview) | | Custom SQL joins | Base tables + [Joining Tables](/docs/data-feeds/joining-overview) | | Understand how fresh/reliable a record is | [Data Freshness](/docs/data-features/data-freshness/data-freshness) | | Find field names and column definitions | [Data Dictionary](/docs/data-features/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.