Building a B2B Marketplace? Here's How to Add Company Profiles with an API

Your B2B marketplace lists hundreds of vendors, but their profiles are sparse — no logo, no employee count, no industry tag, no funding info. Users can't compare, can't filter, can't trust. A company data API fixes this in one sprint. Here's exactly how to build it.

Every successful B2B marketplace — from AWS Marketplace to G2 — shares one trait: rich, structured company profiles. Buyers don't just browse listings; they evaluate vendors. They want to know how big a company is, where it's headquartered, whether it recently raised funding, and what its tech stack looks like. If your marketplace can't answer those questions at a glance, you lose the comparison — and the transaction.

The good news? You don't need vendors to manually fill out 30 form fields. With a company profile API integration, you can auto-populate profiles the moment a vendor signs up — using nothing more than their domain name. This guide walks you through the full architecture, implementation, and optimization of API-enriched company profiles for your B2B marketplace.

Why Rich Company Profiles Matter for Marketplaces

A bare-bones vendor listing with just a company name and email address does almost nothing for your buyers. Here's why investing in rich profiles pays off across every marketplace metric that matters.

Trust and Credibility

When a buyer lands on a vendor profile and sees a professional logo, a verified headquarters location, employee count, and founding year, the profile immediately feels legitimate. According to HubSpot's research on buyer behavior, 81% of B2B buyers need to trust a brand before they'll consider purchasing. Rich profiles are the fastest path to that trust in a marketplace context. Nobody wants to do business with a vendor whose profile looks like it was abandoned halfway through registration.

Discoverability and Search

Structured firmographic data — industry, location, company size, tech stack — transforms your marketplace from a flat list into a searchable, filterable directory. Buyers who arrive looking for "enterprise SaaS vendors in Germany with 50+ employees" need structured data to find what they're looking for. Without it, you're forcing them to click through profiles one by one, which is a UX failure that drives churn.

Comparison and Evaluation

B2B purchases are rarely impulse decisions. Buyers shortlist three to five vendors, compare them side by side, and present options to stakeholders. If your marketplace provides uniform, structured data across all vendor profiles, you become the comparison tool — and comparison tools capture transactions. If you don't, buyers export to a spreadsheet and you lose visibility into the deal entirely.

Conversion Rates

Marketplaces with enriched vendor profiles consistently report higher engagement. NFX's marketplace research shows that profile completeness directly correlates with conversion rates — vendors with complete profiles receive 3-5x more inbound inquiries than sparse ones. The challenge is that most vendors won't fill out detailed profiles manually. An API solves this by doing the work for them.

Filtering and Segmentation

Rich data unlocks advanced filtering: show me vendors funded in the last 12 months, show me companies with 200+ employees, show me SaaS tools that integrate with Salesforce. These filters are impossible without structured, normalized data — and they're exactly what makes a marketplace sticky. Buyers bookmark marketplaces that help them find vendors faster than Google can.

What Data to Add to Vendor/Company Profiles

Not all firmographic fields carry equal weight in a marketplace context. Here's the priority list, ranked by buyer utility and data availability.

Tier 1: Essential Fields

• Company Name — Normalized legal/brand name, not whatever the vendor typed during signup
• Logo — High-resolution logo automatically pulled from the domain; this single field has the biggest visual impact on profile quality
• Industry / Sector — Standardized industry classification (SIC, NAICS, or a custom taxonomy) for filtering
• Company Size — Employee count range (1-10, 11-50, 51-200, 201-500, 500+) for segmentation
• Headquarters Location — City, state/region, country — essential for geo-filtering and compliance
• Description — One to three sentence company overview, auto-generated from public data

Tier 2: High-Value Enrichment

• Founded Year — Signals maturity; buyers often filter by company age
• Funding Status — Total raised, last round type and amount, investor names — critical for trust and momentum signals
• Website URL — Verified primary domain
• Social Links — LinkedIn, Twitter/X, GitHub — buyers use these to verify legitimacy
• Tech Stack — Technologies the vendor uses (detected via their domain) — valuable for integration compatibility

Tier 3: Advanced Differentiators

• Revenue Range — Estimated annual revenue band
• Growth Signals — Recent hiring surges, office expansions, product launches
• Key People — CEO, CTO names and LinkedIn profiles
• Certifications / Compliance — SOC 2, ISO 27001, GDPR compliance status

The beauty of API-driven enrichment is that you can start with Tier 1, launch fast, and progressively add Tier 2 and 3 fields as your marketplace matures. You don't need all 15+ fields on day one.

Architecture: API-Enriched Company Profiles

The enrichment flow is straightforward. Here's the architecture you'll implement, broken down into five stages.

The Enrichment Flow

1. Vendor Signs Up — Vendor provides their business email or company domain during registration
2. Domain Extraction — Your system extracts the root domain from the email (e.g., [email protected] → acmecorp.com)
3. API Enrichment — You call a domain-based company lookup API with the extracted domain
4. Auto-Populate Profile — API response fields are mapped to your database schema and the profile is populated instantly
5. Periodic Refresh — A background job re-enriches profiles every 30-90 days to keep data current

System Diagram

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Vendor      │────▶│  Your API    │────▶│  Company     │
│  Signup Form │     │  Gateway     │     │  Data API    │
└──────────────┘     └──────┬───────┘     └──────┬───────┘
                            │                     │
                            ▼                     ▼
                     ┌──────────────┐     ┌──────────────┐
                     │  Queue       │     │  JSON        │
                     │  (async)     │◀────│  Response    │
                     └──────┬───────┘     └──────────────┘
                            │
                            ▼
                     ┌──────────────┐     ┌──────────────┐
                     │  Field       │────▶│  Vendor      │
                     │  Mapper      │     │  Profile DB  │
                     └──────────────┘     └──────────────┘

Key design decisions: always enrich asynchronously (via a queue), never block the signup flow, and cache API responses aggressively. A vendor's profile might be sparse for the first 5-10 seconds after signup while the enrichment job runs — that's fine. Show a "profile being enriched" indicator and update via websocket or polling.

Data Flow Considerations

One critical architectural choice: what happens when enriched data conflicts with vendor-supplied data? The safest approach is to treat API data as defaults that vendors can override. Auto-populate empty fields, but never overwrite data the vendor has explicitly set. This preserves vendor autonomy while still providing the 80% of data they'd never fill in themselves.

Implementation Guide

Let's build this step by step. The examples below use a Node.js/Express backend, but the patterns apply to any stack — Rails, Django, Laravel, or Go.

Step 1: Domain Extraction

When a vendor signs up with their business email, extract the company domain. Handle edge cases like free email providers (gmail.com, yahoo.com) which shouldn't trigger enrichment.

// utils/domain.js
const FREE_EMAIL_DOMAINS = new Set([
  'gmail.com', 'yahoo.com', 'hotmail.com', 'outlook.com',
  'aol.com', 'icloud.com', 'mail.com', 'protonmail.com'
]);

function extractCompanyDomain(email) {
  if (!email || !email.includes('@')) return null;

  const domain = email.split('@')[1].toLowerCase();

  if (FREE_EMAIL_DOMAINS.has(domain)) {
    return null; // Can't enrich from free email providers
  }

  return domain;
}

// Usage in signup handler
app.post('/api/vendors/register', async (req, res) => {
  const { email, companyName } = req.body;

  // Create vendor record immediately
  const vendor = await Vendor.create({ email, companyName });

  // Extract domain and queue enrichment
  const domain = extractCompanyDomain(email);
  if (domain) {
    await enrichmentQueue.add('enrich-vendor', {
      vendorId: vendor.id,
      domain: domain
    });
  }

  res.status(201).json({ vendor, enrichmentPending: !!domain });
});

Step 2: API Call for Company Data

The enrichment worker calls a domain-based company lookup API to fetch structured company data. Here's the worker implementation:

// workers/enrichVendor.js
const axios = require('axios');

const BOUNCEWATCH_API = 'https://api.bouncewatch.com/v1';

async function enrichVendor(job) {
  const { vendorId, domain } = job.data;

  try {
    // Call the company data API with the domain
    const response = await axios.get(`${BOUNCEWATCH_API}/company/lookup`, {
      headers: {
        'Authorization': `Bearer ${process.env.BOUNCEWATCH_API_KEY}`,
        'Content-Type': 'application/json'
      },
      params: { domain }
    });

    const companyData = response.data;

    if (!companyData || !companyData.name) {
      console.log(`No data found for domain: ${domain}`);
      await markEnrichmentStatus(vendorId, 'not_found');
      return;
    }

    // Map and store the enriched data
    await mapAndStoreProfile(vendorId, companyData);
    await markEnrichmentStatus(vendorId, 'enriched');

  } catch (error) {
    if (error.response?.status === 404) {
      await markEnrichmentStatus(vendorId, 'not_found');
    } else {
      // Retry on transient errors
      throw error;
    }
  }
}

Step 3: Field Mapping

Map the API response to your internal vendor profile schema. This is where you normalize data and handle missing fields gracefully.

// services/profileMapper.js
async function mapAndStoreProfile(vendorId, apiData) {
  const mappedProfile = {
    // Tier 1: Essential
    company_name: apiData.name,
    logo_url: apiData.logo,
    industry: apiData.industry?.primary || apiData.industry,
    employee_count: apiData.metrics?.employees,
    employee_range: categorizeSize(apiData.metrics?.employees),
    city: apiData.location?.city,
    state: apiData.location?.state,
    country: apiData.location?.country,
    description: apiData.description,

    // Tier 2: High-Value
    founded_year: apiData.foundedYear,
    total_funding: apiData.funding?.totalRaised,
    last_funding_round: apiData.funding?.lastRound?.type,
    last_funding_amount: apiData.funding?.lastRound?.amount,
    website_url: apiData.domain ? `https://${apiData.domain}` : null,
    linkedin_url: apiData.socialLinks?.linkedin,
    twitter_url: apiData.socialLinks?.twitter,
    tech_stack: apiData.techStack || [],

    // Metadata
    enriched_at: new Date(),
    enrichment_source: 'bouncewatch_api',
    data_confidence: apiData.confidence || 'high'
  };

  // Only update fields that are currently empty (don't overwrite vendor input)
  await Vendor.updateEmptyFields(vendorId, mappedProfile);
}

function categorizeSize(employees) {
  if (!employees) return 'Unknown';
  if (employees <= 10) return '1-10';
  if (employees <= 50) return '11-50';
  if (employees <= 200) return '51-200';
  if (employees <= 500) return '201-500';
  if (employees <= 1000) return '501-1000';
  return '1000+';
}

Step 4: Database Schema

Your vendor profiles table needs to accommodate enriched data alongside user-supplied data. Here's a migration that adds the necessary columns:

// migrations/add_enrichment_fields_to_vendors.js
exports.up = function(knex) {
  return knex.schema.alterTable('vendors', (table) => {
    // Enrichment metadata
    table.enum('enrichment_status', [
      'pending', 'enriched', 'not_found', 'stale'
    ]).defaultTo('pending');
    table.timestamp('enriched_at').nullable();
    table.string('enrichment_source').nullable();

    // Firmographic fields
    table.string('logo_url', 500).nullable();
    table.string('industry').nullable();
    table.integer('employee_count').nullable();
    table.string('employee_range').nullable();
    table.string('city').nullable();
    table.string('state').nullable();
    table.string('country').nullable();
    table.text('description').nullable();
    table.integer('founded_year').nullable();

    // Funding data
    table.bigInteger('total_funding').nullable();
    table.string('last_funding_round').nullable();
    table.bigInteger('last_funding_amount').nullable();

    // Social and web
    table.string('linkedin_url', 500).nullable();
    table.string('twitter_url', 500).nullable();
    table.jsonb('tech_stack').defaultTo('[]');

    // Indexes for filtering
    table.index('industry');
    table.index('employee_range');
    table.index('country');
    table.index('enrichment_status');
  });
};

Step 5: Display Component

With the data stored, build a vendor profile component that renders beautifully whether the profile is fully enriched, partially enriched, or still pending.

// components/VendorProfile.jsx
function VendorProfile({ vendor }) {
  return (
    <div className="vendor-profile">
      <div className="profile-header">
        {vendor.logo_url ? (
          <img src={vendor.logo_url} alt={vendor.company_name}
               className="vendor-logo" />
        ) : (
          <div className="logo-placeholder">
            {vendor.company_name?.charAt(0)}
          </div>
        )}

        <div className="header-info">
          <h1>{vendor.company_name}</h1>
          <p className="meta">
            {vendor.industry && <span className="tag">{vendor.industry}</span>}
            {vendor.employee_range &&
              <span className="tag">{vendor.employee_range} employees</span>}
            {vendor.country &&
              <span className="tag">{vendor.city}, {vendor.country}</span>}
          </p>
          {renderSignalBadges(vendor)}
        </div>
      </div>

      {vendor.description && (
        <p className="description">{vendor.description}</p>
      )}

      <div className="profile-grid">
        <DetailCard label="Founded" value={vendor.founded_year} />
        <DetailCard label="Employees" value={vendor.employee_count?.toLocaleString()} />
        <DetailCard label="Total Funding"
          value={vendor.total_funding ? formatCurrency(vendor.total_funding) : null} />
        <DetailCard label="Last Round"
          value={vendor.last_funding_round} />
      </div>

      {vendor.tech_stack?.length > 0 && (
        <div className="tech-stack">
          <h3>Tech Stack</h3>
          {vendor.tech_stack.map(tech =>
            <span key={tech} className="tech-tag">{tech}</span>
          )}
        </div>
      )}
    </div>
  );
}

Handling Edge Cases

Production-grade enrichment needs to handle the messy realities of company data. Here are the edge cases you'll encounter and how to address each one.

Company Not Found

Not every domain will return a match. Small businesses, very new startups, and companies with unusual domain structures may not be in any data provider's index. Your strategy:

• Set enrichment_status = 'not_found' and display the vendor-supplied data as-is
• Retry enrichment after 30 days — the company may have been indexed by then
• Offer a manual profile completion prompt to the vendor: "We couldn't auto-fill your profile. Complete it now to increase visibility."
• Never show a broken or empty profile — always fall back to whatever data you have

Multiple Matches

Some domains map to parent companies, subsidiaries, or acquired entities. A query for meta.com might return Facebook, Meta Platforms, or Instagram depending on the API's resolution logic. Handle this by:

• Using the primary/canonical match from the API response
• Storing alternative matches for admin review
• Allowing vendors to select the correct entity if the auto-match seems wrong

Stale Data

Company data changes constantly — companies rebrand, relocate, raise new rounds, hire aggressively, or downsize. Your periodic refresh job should run every 30-90 days depending on your marketplace's activity level. As outlined in our guide on keeping enrichment data fresh, the key is implementing a smart refresh schedule:

// jobs/refreshStaleProfiles.js
async function refreshStaleProfiles() {
  const staleThreshold = new Date();
  staleThreshold.setDate(staleThreshold.getDate() - 60); // 60-day refresh cycle

  const staleVendors = await Vendor.findAll({
    where: {
      enrichment_status: 'enriched',
      enriched_at: { [Op.lt]: staleThreshold }
    },
    limit: 100 // Process in batches
  });

  for (const vendor of staleVendors) {
    await enrichmentQueue.add('enrich-vendor', {
      vendorId: vendor.id,
      domain: vendor.domain,
      isRefresh: true
    }, { priority: 'low' });
  }
}

International Companies

Companies outside the US and Western Europe may have less complete data coverage. Handle this by:

• Accepting partial enrichment — a company name and country is still better than nothing
• Using the data_confidence field to indicate coverage quality
• Supplementing with local data sources for underserved regions
• Normalizing country names and location formats to a consistent standard (ISO 3166)

Recently Founded Startups

Pre-seed and early-stage startups may have minimal public data. They often lack funding records, have fluctuating employee counts, and may not appear in traditional databases. For these vendors, prioritize whatever data is available and surface it clearly rather than showing empty fields. Even a logo, founding year, and location significantly improve profile quality.

Adding Signal Badges

Here's where marketplace enrichment gets truly powerful. Beyond static firmographic data, you can overlay real-time signal badges on vendor profiles to communicate momentum, trust, and urgency to buyers.

What Are Signal Badges?

Signal badges are dynamic visual indicators derived from company activity data. They tell buyers not just who a vendor is, but what's happening with them right now. Think of them as verified trust signals that update automatically.

Key Badge Types

• "Recently Funded" — The vendor raised a funding round in the last 6 months. This signals financial stability, growth trajectory, and the ability to invest in their product. Buyers are more confident purchasing from a funded company.
• "Hiring" — The vendor's headcount grew 20%+ in the last quarter. This indicates expansion and suggests the company is scaling to meet demand — a positive signal for marketplace buyers evaluating long-term vendor viability.
• "Expanding" — The vendor opened a new office or entered a new market. Relevant for buyers who need local support or regional presence.
• "Trending" — The vendor profile received unusually high view counts on your marketplace. Social proof that drives more engagement.

Implementation

// services/signalBadges.js
async function getVendorBadges(vendor) {
  const badges = [];

  // Recently Funded badge
  if (vendor.last_funding_date) {
    const sixMonthsAgo = new Date();
    sixMonthsAgo.setMonth(sixMonthsAgo.getMonth() - 6);

    if (new Date(vendor.last_funding_date) > sixMonthsAgo) {
      badges.push({
        type: 'recently_funded',
        label: 'Recently Funded',
        detail: `${vendor.last_funding_round} — ${formatCurrency(vendor.last_funding_amount)}`,
        color: 'green',
        icon: 'trending-up',
        url: '/signals/recently-funded'
      });
    }
  }

  // Hiring Surge badge
  if (vendor.employee_growth_pct && vendor.employee_growth_pct > 20) {
    badges.push({
      type: 'hiring_surge',
      label: 'Hiring',
      detail: `+${vendor.employee_growth_pct}% headcount growth`,
      color: 'blue',
      icon: 'users-plus',
      url: '/signals/hiring-surge'
    });
  }

  // Expanding badge
  if (vendor.new_locations && vendor.new_locations.length > 0) {
    badges.push({
      type: 'expanding',
      label: 'Expanding',
      detail: `New office in ${vendor.new_locations[0]}`,
      color: 'purple',
      icon: 'map-pin'
    });
  }

  return badges;
}

Signal badges transform passive vendor directories into living, dynamic marketplaces. Buyers return to check what's changed. Vendors are incentivized to keep profiles updated. Everyone benefits.

For a deeper look at the signal types available, explore the BounceWatch company directory — every company profile includes live signal indicators powered by the same API you'd integrate into your marketplace.

Cost Analysis

Let's talk economics. Enrichment isn't free, but it's dramatically cheaper than the alternative (manual data entry, or worse, sparse profiles that kill your marketplace's conversion rate).

Per-Vendor Enrichment Cost

Most company data APIs charge per lookup. Pricing typically falls into these ranges:

Marketplace Size	Vendors	Initial Enrichment	Annual Refresh (4x/yr)	Estimated Cost
Early Stage	100-500	500 calls	2,000 calls	$50-150/month
Growth	500-5,000	5,000 calls	20,000 calls	$150-500/month
Scale	5,000-50,000	50,000 calls	200,000 calls	$500-2,000/month

Compare this to the cost of manual data entry: at 15 minutes per profile and $25/hour, enriching 1,000 vendors manually costs $6,250 — and the data is stale the moment it's entered. API enrichment at scale is 10-50x cheaper than manual alternatives and produces more accurate, fresher data.

Caching Strategy

Smart caching reduces API costs significantly. Here's a tiered caching approach recommended by engineering teams at companies like Stripe for high-volume API integrations:

// services/enrichmentCache.js
class EnrichmentCache {
  constructor(redis) {
    this.redis = redis;
    this.DB_CACHE_DAYS = 60;     // Database: 60-day cache
    this.REDIS_CACHE_HOURS = 24; // Redis: 24-hour hot cache
  }

  async lookup(domain) {
    // Layer 1: Redis hot cache (sub-ms response)
    const cached = await this.redis.get(`company:${domain}`);
    if (cached) {
      return { data: JSON.parse(cached), source: 'cache' };
    }

    // Layer 2: Database cache (check if recently enriched)
    const dbRecord = await CompanyCache.findOne({
      where: {
        domain,
        fetched_at: {
          [Op.gt]: new Date(Date.now() - this.DB_CACHE_DAYS * 86400000)
        }
      }
    });

    if (dbRecord) {
      // Promote to Redis for faster subsequent access
      await this.redis.setex(
        `company:${domain}`,
        this.REDIS_CACHE_HOURS * 3600,
        JSON.stringify(dbRecord.data)
      );
      return { data: dbRecord.data, source: 'db_cache' };
    }

    // Layer 3: Fresh API call
    return null; // Caller should fetch from API
  }

  async store(domain, data) {
    // Store in both layers
    await CompanyCache.upsert({ domain, data, fetched_at: new Date() });
    await this.redis.setex(
      `company:${domain}`,
      this.REDIS_CACHE_HOURS * 3600,
      JSON.stringify(data)
    );
  }
}

Optimization for High-Volume Marketplaces

If your marketplace processes thousands of new vendors monthly, additional optimizations apply:

• Batch enrichment — Queue new signups and process them in batches of 50-100 to reduce API overhead and leverage bulk pricing
• Domain deduplication — Multiple vendors from the same company share one enrichment call. Cache by domain, not by vendor ID
• Tiered refresh schedules — Active vendors (logged in within 30 days) refresh every 60 days; dormant vendors refresh every 180 days
• Webhook-driven updates — Instead of polling, subscribe to webhooks for funding events, hiring surges, and other signals to update profiles in real time
• Progressive enrichment — Fetch Tier 1 data immediately (cheap, fast), then fetch Tier 2-3 data on first profile view (lazy enrichment saves calls for vendors nobody looks at)

As a16z notes in their marketplace analyses, the best marketplaces treat data quality as a competitive moat. Every dollar spent on enrichment compounds — richer profiles attract more buyers, more buyers attract more vendors, and the flywheel accelerates.

ROI Calculation

For a growth-stage marketplace spending $300/month on enrichment:

• If enriched profiles convert even 1% better (very conservative), and your average deal size is $5,000
• On 1,000 vendor profiles generating 50 inquiries/month → 0.5 additional conversions/month
• That's $2,500/month in incremental revenue against $300 in enrichment cost
• ROI: 8.3x — and this ignores the compounding effects of better SEO, higher engagement, and improved marketplace reputation

Putting It All Together

Building API-enriched company profiles for your B2B marketplace isn't a moonshot — it's a weekend sprint. To recap the implementation path:

1. Extract domains from vendor emails at signup
2. Queue asynchronous enrichment calls to a company data API
3. Map response fields to your vendor profile schema
4. Display enriched profiles with graceful fallbacks for missing data
5. Add signal badges for real-time momentum indicators
6. Implement tiered caching to control costs at scale
7. Schedule periodic refreshes to keep data current

The result: a marketplace where every vendor profile looks complete, trustworthy, and current — even if the vendor never filled in a single field beyond their email address. Buyers can filter, compare, and evaluate with confidence. Your conversion rates climb. Your marketplace compounds.

For further reading, check out our guides on building a company enrichment pipeline and domain-based company lookup. And if you're building with modern web frameworks, the integration is even simpler — most company data APIs return clean JSON that maps directly to your component props.