@memberjunction/actions-apollo

Apollo.io data enrichment action classes for MemberJunction that enable automated enrichment of contact and account records using the Apollo.io API.

Overview

This package provides two server-side action classes that integrate with Apollo.io's data enrichment services to automatically populate account and contact records with company information, social profiles, technology stacks, employment history, and education data. Both actions extend BaseAction from @memberjunction/actions and are registered via @RegisterClass for automatic discovery by the MemberJunction Actions engine.

Key capabilities:

• Account enrichment -- company address, phone, description, social URLs, technology stacks, and associated contacts discovered via organization domain lookup
• Contact enrichment -- bulk email verification, social profile URLs, employment history, and education history via people matching
• Configurable field mappings -- JSON-based parameter configuration maps Apollo.io fields to your custom entity fields
• Rate limit handling -- automatic retry with intelligent backoff for both per-minute and hourly Apollo.io rate limits
• Batch processing -- concurrent group processing with configurable batch sizes and pagination for large datasets
• List management, search and prospecting -- seven further actions that read and create Apollo lists (labels), page through a list's members, search Apollo's people database for net-new prospects, and move records between lists without destroying their other memberships. See List management, search and prospecting

For general Actions framework architecture and design philosophy, see the parent Actions README and Actions CLAUDE.md.

Architecture

flowchart TB
    subgraph Engine["MemberJunction Actions Engine"]
        AE["ActionEngineServer"]
    end

    subgraph Apollo["@memberjunction/actions-apollo"]
        AccAction["ApolloEnrichmentAccountsAction"]
        ConAction["ApolloEnrichmentContactsAction"]
        PeopleClient["ApolloPeopleClient\n(bulk_match, organizations/enrich)"]
        RESTClient["ApolloRESTClient\n(lists, api_search)"]
        Http["ApolloHttp\n(header auth, typed errors)"]
        Config["Configuration\n(batch sizes, endpoints)"]
        Types["Apollo Type Definitions"]
    end

    subgraph ApolloAPI["Apollo.io REST API"]
        OrgEnrich["/organizations/enrich"]
        BulkMatch["/people/bulk_match"]
        PeopleSearch["/mixed_people/api_search"]
    end

    subgraph MJCore["MemberJunction Core"]
        Meta["Metadata"]
        RV["RunView"]
        BE["BaseEntity"]
    end

    AE -->|executes| AccAction
    AE -->|executes| ConAction
    AccAction --> Config
    ConAction --> Config
    AccAction --> Types
    ConAction --> Types
    AccAction --> PeopleClient
    AccAction --> RESTClient
    ConAction --> PeopleClient
    PeopleClient --> Http
    RESTClient --> Http
    Http --> OrgEnrich
    Http --> BulkMatch
    Http --> PeopleSearch
    AccAction -->|read/write entities| MJCore
    ConAction -->|read/write entities| MJCore

    style Engine fill:#2d6a9f,stroke:#1a4971,color:#fff
    style Apollo fill:#7c5295,stroke:#563a6b,color:#fff
    style ApolloAPI fill:#b8762f,stroke:#8a5722,color:#fff
    style MJCore fill:#2d8659,stroke:#1a5c3a,color:#fff
Copy

Account Enrichment Data Flow

flowchart LR
    Start["Load accounts\nmatching filter"] --> OrgAPI["Call /organizations/enrich\nper domain"]
    OrgAPI --> UpdateAcct["Update account\nfields"]
    OrgAPI --> TechRec["Create/update\ntechnology records"]
    OrgAPI --> PeopleAPI["Call /mixed_people/api_search\nfor the ids at the domain (free)"]
    PeopleAPI --> Match["Call /people/bulk_match\nby id, 10 at a time (1 credit per match)"]
    Match --> CreateContact["Create/update\ncontact records"]
    CreateContact --> History["Create education\nhistory records"]
    UpdateAcct --> Next["Next account"]
    TechRec --> Next
    History --> Next

    style Start fill:#2d6a9f,stroke:#1a4971,color:#fff
    style OrgAPI fill:#b8762f,stroke:#8a5722,color:#fff
    style UpdateAcct fill:#2d8659,stroke:#1a5c3a,color:#fff
    style TechRec fill:#2d8659,stroke:#1a5c3a,color:#fff
    style PeopleAPI fill:#b8762f,stroke:#8a5722,color:#fff
    style Match fill:#b8762f,stroke:#8a5722,color:#fff
    style CreateContact fill:#2d8659,stroke:#1a5c3a,color:#fff
    style History fill:#2d8659,stroke:#1a5c3a,color:#fff
    style Next fill:#64748b,stroke:#475569,color:#fff
Copy

Contact Enrichment Data Flow

flowchart LR
    Start["Keyset-page contacts\nmatching filter"] --> Batch["Batch into groups\nof 10"]
    Batch --> BulkAPI["Call /people/bulk_match\nper batch"]
    BulkAPI --> Update["Update matched fields;\nstamp EnrichedAt on every row sent"]
    Update --> EmpHist["Upsert employment\nhistory"]
    Update --> EduHist["Upsert education\nhistory"]
    EmpHist --> NextBatch["Next batch"]
    EduHist --> NextBatch

    style Start fill:#2d6a9f,stroke:#1a4971,color:#fff
    style Batch fill:#64748b,stroke:#475569,color:#fff
    style BulkAPI fill:#b8762f,stroke:#8a5722,color:#fff
    style Update fill:#2d8659,stroke:#1a5c3a,color:#fff
    style EmpHist fill:#7c5295,stroke:#563a6b,color:#fff
    style EduHist fill:#7c5295,stroke:#563a6b,color:#fff
    style NextBatch fill:#64748b,stroke:#475569,color:#fff
Copy

Installation

npm install @memberjunction/actions-apollo
Copy

Prerequisites

1. An active Apollo.io account with API access
2. An Apollo.io API key, either as the environment variable APOLLO_API_KEY or on a company's MJ: Company Integrations row for the Apollo Integration (passed as the CompanyID param; see Credentials)
3. MemberJunction framework properly configured with server-side action engine
4. Target entities configured for storing enriched data (accounts, contacts, technologies, etc.)

Configuration

Environment Variables

APOLLO_API_KEY=your_apollo_api_key_here
Copy

Configuration Constants

The package defines the following defaults in config.ts:

Usage

Account Enrichment

The ApolloEnrichmentAccountsAction enriches account/organization records by looking up company information using domain names. It can optionally discover contacts at the organization, track technology stacks, and create education history records.

Parameters

AccountEntityFields Structure

{
    EntityName: string;          // Target entity name (e.g., "Accounts")
    DomainField: string;         // Field containing company domain
    AccountIDField: string;      // Primary key field name
    EnrichedAtField: string;     // Timestamp field for tracking enrichment
    Filter: string;              // SQL filter for selecting records to process
    AddressField?: string;       // Street address
    CityField?: string;          // City
    StateProvinceField?: string; // State/province
    PostalCodeField?: string;    // Postal code
    DescriptionField?: string;   // Company description
    PhoneNumberField?: string;   // Phone number
    CountryField?: string;       // Country
    LinkedInField?: string;      // LinkedIn URL
    LogoURLField?: string;       // Company logo URL
    FacebookField?: string;      // Facebook URL
    TwitterField?: string;       // Twitter URL
}
Copy

Example

import { ActionEngineServer } from '@memberjunction/actions';

const engine = ActionEngineServer.Instance;

const result = await engine.RunAction({
    ActionName: 'ApolloEnrichmentAccountsAction',
    Params: [
        {
            Name: 'AccountEntityFieldMappings',
            Value: JSON.stringify({
                EntityName: 'Accounts',
                DomainField: 'Domain',
                AccountIDField: 'ID',
                EnrichedAtField: 'LastEnrichedAt',
                Filter: 'Domain IS NOT NULL AND LastEnrichedAt IS NULL',
                CityField: 'City',
                StateProvinceField: 'StateProvince',
                LinkedInField: 'LinkedInURL',
                DescriptionField: 'Description'
            })
        },
        {
            Name: 'AccountTechnologyEntityFieldMappings',
            Value: JSON.stringify({
                EntityName: 'Account Technologies',
                AccountIDField: 'AccountID',
                TechnologyIDField: 'TechnologyID',
                TechnologyField: 'Technology',
                CategoryField: 'Category',
                EndedUseAtField: 'EndedUseAt'
            })
        },
        {
            Name: 'ContactEntityFieldMappings',
            Value: JSON.stringify({
                EntityName: 'Contacts',
                EmailField: 'Email',
                AccountIDField: 'AccountID',
                EnrichedAtField: 'LastEnrichedAt',
                FirstNameField: 'FirstName',
                LastNameField: 'LastName',
                TitleField: 'Title',
                EmailSourceField: 'EmailSource',
                ActivityCountField: 'ActivityCount'
            })
        }
    ],
    ContextUser: contextUser
});
Copy

Contact Enrichment

The ApolloEnrichmentContactsAction enriches existing contact records by matching on name and email combinations through Apollo's bulk people matching API.

Parameters

Every record the action sends to Apollo is stamped with EnrichedAtField, whether or not Apollo matched it, so a Filter on that stamp (as in the example) never re-sends, and never pays for, the same miss. Records nothing identifies (no email, and not a first and last name with a domain or account name) are stamped without a lookup.

EmploymentHistoryFieldMappings Structure

Keys are matched case-insensitively. Only the columns named here are ever written.

{
    EntityName: string;             // Employment history entity
    ContactIDFieldName: string;     // Foreign key to contact (the contact entity must have a single-column key)
    OrganizationFieldName: string;  // Organization name field
    TitleFieldName: string;         // Job title field
    StartDateFieldName?: string;    // Optional: start date
    EndDateFieldName?: string;      // Optional: end date
    IsCurrentFieldName?: string;    // Optional: current-position flag
}
Copy

EducationHistoryFieldMappings Structure

Education is written whenever this mapping is present, independently of the employment mapping. Apollo returns education as employment_history entries that carry a degree or an education kind; the client files those under education and everything else (a trustee seat at a university, say) under employment.

{
    EntityName: string;             // Education history entity
    ContactIDFieldName: string;     // Foreign key to contact
    InstitutionFieldName: string;   // Institution name field
    DegreeFieldName: string;        // Degree field
    GradeLevelFieldName?: string;   // Optional: grade level
    StartDateFieldName?: string;    // Optional: start date
    EndDateFieldName?: string;      // Optional: end date
}
Copy

Example

import { ActionEngineServer } from '@memberjunction/actions';

const engine = ActionEngineServer.Instance;

const result = await engine.RunAction({
    ActionName: 'ApolloEnrichmentContactsAction',
    Params: [
        { Name: 'EntityName', Value: 'Contacts' },
        { Name: 'EmailField', Value: 'Email' },
        { Name: 'FirstNameField', Value: 'FirstName' },
        { Name: 'LastNameField', Value: 'LastName' },
        { Name: 'TitleField', Value: 'Title' },
        { Name: 'EnrichedAtField', Value: 'LastEnrichedAt' },
        { Name: 'Filter', Value: 'Email IS NOT NULL AND LastEnrichedAt IS NULL' },
        { Name: 'DomainField', Value: 'Domain' },
        { Name: 'LinkedInField', Value: 'LinkedInURL' },
        {
            Name: 'EmploymentHistoryFieldMappings',
            Value: JSON.stringify({
                EntityName: 'Contact Employment Histories',
                ContactIDFieldName: 'ContactID',
                OrganizationFieldName: 'Organization',
                TitleFieldName: 'Title',
                StartDateFieldName: 'StartedAt',
                EndDateFieldName: 'EndedAt',
                IsCurrentFieldName: 'IsCurrent'
            })
        },
        {
            Name: 'EducationHistoryFieldMappings',
            Value: JSON.stringify({
                EntityName: 'Contact Education Histories',
                ContactIDFieldName: 'ContactID',
                InstitutionFieldName: 'Institution',
                DegreeFieldName: 'Degree'
            })
        }
    ],
    ContextUser: contextUser
});
Copy

List management, search and prospecting

Seven actions cover the other half of Apollo: which records are on which list, and moving them between lists. They are the outbound-campaign surface — build a list, drain it through a sequence of stages, and see what is where.

Every client in this package now talks to api.apollo.io/api/v1 (ApolloRESTEndpoint), which serves enrichment, search and lists alike; the older api.apollo.io/v1 constant remains exported but unused. All HTTP goes through src/http/ApolloHttp.ts: X-Api-Key header auth, JSON handling, and typed errors (ApolloAuthError for 401/403, ApolloRateLimitError with the window for 429, ApolloRequestError otherwise).

The five Apollo behaviours these encode

These are the load-bearing part. They are documented in full on src/generic/apollo-lists.types.ts and referenced by number throughout the client.

1. A PATCH replaces the whole label_names array. There is no add-one-label call, so a move is two writes, each carrying the complete intended set: first current ∪ {toList}, then (current ∪ {toList}) \ {fromList}. Writing a bare ['Warm'] would silently delete every other list the record was on — and nothing in the response would say so. This is why the move actions re-read the source list for current labels and only accept ids from the caller, never labels.
2. Roughly 15–17% of removes return success without applying. Removes are therefore verified by re-reading the destination list, and a record still carrying the source label is reported as possiblyStuck — never auto-retried, because an immediate retry flakes the same way. The next page-1 drain sees it carrying both labels and finishes the job. A possibly-stuck record is not a failure: the write succeeded and Apollo did not honour it.
3. A list drain always reads page 1. Removing records shifts every later page, so advancing to page 2 skips records. Paging therefore defaults to page 1 rather than to "wherever you left off".
4. Label reads and every write need a MASTER API key. A scoped key authenticates fine and then 403s, which is indistinguishable from a wrong key — so the client rewrites that 403 into a message naming the requirement.
5. Labels are read as label_ids but written as label_names. The client fetches the label list once per instance and resolves ids to names on every read. An id with no matching label is dropped rather than passed through, since a raw id inside a label_names write would create a label named after a hex string.

Credentials

Two paths, in order:

1. A CompanyID param → that company's active Apollo MJ: Company Integrations row → its CredentialID → the apiKey inside MJ: Credentials Values. This is the multi-tenant path.
2. APOLLO_API_KEY from the environment, which is what the enrichment actions have always used. Single-tenant deployments keep working with no credential rows.

Every action reports which path supplied its key as a KeySource output.

CompanyIntegration.APIKey is deliberately not read. That column is not a decrypt-on-read field, so a key written through metadata sync comes back as the literal ciphertext string $ENC$…; sending that to Apollo produces a 401 that looks exactly like a wrong key. MJ: Credentials is the field that decrypts, so it is the only one used. A credential that exists but whose Values will not parse fails with CONFIGURATION_ERROR rather than falling back to the environment — a broken credential should not silently borrow another workspace's key.

A typical drain

// 1. See the real label names.
await engine.RunAction({ Action: getLists, Params: [], ContextUser: contextUser });

// 2. Read page 1 of the source list — this is where current label names come from.
const page = await engine.RunAction({
    Action: getListAccounts,
    Params: [{ Name: 'ListName', Value: 'Cold Outreach', Type: 'Input' }],
    ContextUser: contextUser
});

// 3. Move by id. The action re-reads page 1 itself, so the labels it writes are
//    never the ones you read above going stale in between.
await engine.RunAction({
    Action: moveListAccounts,
    Params: [
        { Name: 'AccountIDs', Value: ['5f2a…', '5f2b…'], Type: 'Input' },
        { Name: 'FromList', Value: 'Cold Outreach', Type: 'Input' },
        { Name: 'ToList', Value: 'Engaged', Type: 'Input' }
    ],
    ContextUser: contextUser
});
Copy

Every list param (AccountIDs, Titles, Seniorities, …) accepts a real array, a JSON array string, or a comma-separated string, because these actions get called from an agent input mapping, from an LLM writing params, and from a human typing in a UI. Genuinely malformed input still fails loudly rather than becoming an empty filter — on a people search that is the difference between a scoped query and an unscoped firehose.

Additional endpoints

There is no delete surface. The only writes are label-array replacements and label creation.

API Reference

Exported Classes

ApolloEnrichmentAccountsAction

Registered as "ApolloEnrichmentAccountsAction" via @RegisterClass(BaseAction). Extends BaseAction.

Processing behavior:

• Queries accounts matching the configured filter
• For each account, calls /organizations/enrich with the domain
• Updates account fields with enriched organization data
• Optionally creates/updates technology stack records with historical tracking (marks ended technologies)
• Optionally discovers contacts: /mixed_people/api_search for the ids at the domain (free), then /people/bulk_match by id (one credit per match, up to MaxPeopleToEnrichPerOrg), creating or updating a contact for each in-domain email
• Looks contacts up by their real primary keys, quoted per column type, so UUID and integer keys both work
• Processes recursively up to 5 times to handle remaining records; every save runs even after an earlier one fails

ApolloEnrichmentContactsAction

Registered as "ApolloEnrichmentContactsAction" via @RegisterClass(BaseAction). Extends BaseAction.

Processing behavior:

• Pages through contact records matching the configured filter (500 per page) by keyset on a single-column key, so a filter that drains as rows are stamped cannot skip rows; a composite-key entity re-reads the first page excluding rows stamped this run
• Batches contacts into groups of 10 for Apollo's /people/bulk_match endpoint through ApolloPeopleClient
• Updates matching contacts with enriched social profiles and company data, and stamps every row sent
• Optionally creates/updates employment and education history records, each from its own mapping, writing only the columns the mapping names and storing values as Apollo sent them
• Returns RATE_LIMIT_EXCEEDED at once on an hourly or daily Apollo limit (the client retries a per-minute limit once, after at most 60 seconds)

Exported Types

All types are exported from src/generic/apollo.types.ts:

ApolloPeopleClient

src/people/ApolloPeopleClient.ts. The table-agnostic enrichment client both actions use, and the one the BizApps Common person-enrichment engine wraps. It returns normalized data and writes nothing.

• BulkMatch(inputs, { RevealPersonalEmails?, IncludeRaw? }): up to MaxBatchSize (10) people per call; each input needs an Apollo id, an email, a LinkedIn URL, or a first and last name with an organization. Results come back in input order with the caller's Key; a miss is Matched: false. CreditsConsumed is Apollo's count (one per match, misses free). The education split described above lives here.
• EnrichOrganization(domain): organizations/enrich, null on a miss.
• ForCompany(companyID, contextUser): resolves the key through the credentials path (company credential, then APOLLO_API_KEY).
• A per-minute 429 waits at most 60 seconds and retries once; an hourly or daily 429 throws ApolloRateLimitError immediately. The client never sleeps longer than a minute.

Rate Limiting and Error Handling

All HTTP goes through src/http/ApolloHttp.ts, which maps failures onto typed errors:

• ApolloRateLimitError (429) carries Window (minute, hour, day, unknown) and RetryAfterSeconds. The people client retries a per-minute limit once after at most 60 seconds; the actions return RATE_LIMIT_EXCEEDED immediately on any other window, so a scheduled job never holds its lock through an hour-long sleep.
• ApolloAuthError (401, 403) becomes CONFIGURATION_ERROR; a 403 on a master-key operation says so.
• ApolloRequestError for anything else, with the status and the body Apollo sent.
• Everything is logged via MemberJunction's LogError and LogStatus utilities.

Title Filtering

Both actions automatically exclude contacts with the following job titles to maintain data quality:

• member
• student member
• student
• volunteer

Apollo.io API Endpoints Used

Dependencies

Limitations

• Maximum 10 records per bulk API request (Apollo.io API limitation)
• Rate limits apply based on your Apollo.io subscription tier; a per-minute limit is retried once, an hourly or daily limit ends the run with RATE_LIMIT_EXCEEDED
• Personal emails may not be revealed in GDPR-compliant regions
• Account enrichment processes domains one at a time and discovers at most MaxPeopleToEnrichPerOrg (500) people per organization, each matched person costing one credit
• Contact enrichment on a composite-key entity pages by re-reading the first page of rows not yet stamped this run; a row whose save fails is skipped for the rest of the run
• Account enrichment recurses up to 5 times to prevent infinite loops
• Excluded job titles (member, student member, student, volunteer) are automatically skipped

Related Packages

• @memberjunction/actions-base -- Base classes and types used by all action packages
• @memberjunction/actions -- Server-side action engine that discovers and executes actions
• @memberjunction/core-actions -- Collection of 40+ pre-built MemberJunction actions
• @memberjunction/actions-content-autotag -- Content tagging and vectorization actions