.png)
Oracle Eloqua Marketing Automation Integration Guide
Integrate Oracle Eloqua with enterprise systems through REST and Bulk APIs, selected webhook notifications, scheduled workflows, and secure authentication.
Oracle Eloqua Marketing Automation integration options at a glance
Oracle Eloqua provides REST APIs for Contacts, Accounts, Campaigns, Emails, activities, assets, segments, and Custom Objects. Its Bulk APIs support high-volume and asynchronous imports, exports, migrations, and scheduled synchronization. Eloqua also supports webhook-style notifications for selected events, while legacy SOAP capabilities may be relevant to existing implementations. OAuth 2.0 is the preferred modern authentication approach, with OAuth 1.0a and Basic Authentication available in some scenarios. Martini can consume these APIs, orchestrate bulk-job lifecycles, receive supported notifications, transform Eloqua JSON, apply consent and matching rules, and expose controlled APIs for downstream systems.
| Integration point | Supported by Oracle Eloqua Marketing Automation? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage and query Contacts, Accounts, Campaigns, Emails, activities, assets, segments, and Custom Objects for transactional or moderate-volume integration. | Martini can consume Eloqua REST endpoints, authenticate requests, map JSON payloads, expose controlled APIs, and orchestrate downstream writes. |
| Bulk / async / batch APIs | Yes | Perform high-volume exports, imports, initial migrations, scheduled audience synchronization, historical activity extraction, and large-scale corrections. | Martini can submit bulk jobs, persist job identifiers, poll status, retrieve results, separate successful and failed rows, and retry eligible failures. |
| Webhooks / outbound callbacks | Limited | Receive webhook-style notifications for selected Eloqua events or resources where the required event is supported. | Martini can expose an API endpoint, validate and deduplicate notifications, retrieve current Eloqua state, and process downstream work asynchronously. |
| SOAP APIs | Legacy | Support existing Eloqua integrations that depend on legacy SOAP operations unavailable through current REST or Bulk interfaces. | Martini can consume SOAP services when required, while keeping REST and Bulk APIs as the preferred design for new implementations. |
| File / asset APIs | Limited | Access marketing assets and file-oriented Eloqua resources, including email-related assets; these APIs are not a general-purpose file-transfer service. | Martini can retrieve, transform, validate, and route supported asset payloads, using Bulk APIs instead for large data movement where appropriate. |
| Database / analytics access | Limited | Retrieve reporting, activity, or analytics data through available APIs or Oracle-supported analytics services where provisioned. | Martini can consume supported reporting interfaces or write extracted data to a database, but it does not rely on direct Eloqua database access. |
| Authentication | Yes | Authenticate integrations with OAuth 2.0, and in applicable legacy or deployment-specific scenarios OAuth 1.0a or Basic Authentication. | Martini can keep OAuth clients, tokens, credentials, pod URLs, and environment-specific settings in secure configuration rather than workflow logic. |
How Oracle Eloqua Marketing Automation exposes data and business events
Oracle Eloqua REST APIs
Eloqua REST APIs are the primary interface for synchronous application integration. They provide access to Contacts, Accounts, Campaigns, Emails, activities, assets, segments, Custom Objects, and other marketing resources.
Martini implementation pattern
Martini consumes the relevant Eloqua REST endpoint from a workflow, authenticates with environment-specific credentials, handles pagination and response validation, maps Eloqua JSON into a canonical or target model, and applies business rules before writing to another system. Martini can also expose a controlled REST API for applications that need an Eloqua-backed service.
Implementation sequence
Oracle Eloqua Bulk APIs
Eloqua Bulk APIs support high-volume and asynchronous imports and exports. They are appropriate for migrations, large Contact updates, scheduled audience synchronization, and historical activity extraction.
Martini implementation pattern
Martini orchestrates the complete bulk-job lifecycle rather than treating submission as completion. A workflow submits a definition or job, stores its identifier, polls for status, retrieves successful and failed results, transforms batches, and records the outcome. Retry logic can target transient failures or failed rows without resubmitting completed work.
Implementation sequence
Oracle Eloqua Webhook Notifications
Eloqua supports webhook-style notifications for selected events and resources, but coverage is not universal. Each required event must be confirmed before relying on notifications as the trigger.
Martini implementation pattern
Martini exposes a secured API endpoint to receive the notification, validates the request, detects duplicate deliveries, and acknowledges quickly where appropriate. The workflow can then retrieve current Eloqua state before applying business rules and routing the event to Salesforce, ServiceNow, or another service. Unsupported events use scheduled polling or Bulk extraction instead.
Implementation sequence
Oracle Eloqua SOAP APIs
Eloqua has legacy SOAP capabilities that may be required by existing implementations. REST and Bulk APIs remain the preferred interfaces for new integrations.
Martini implementation pattern
When a required legacy operation is unavailable through REST or Bulk APIs, Martini can consume the SOAP service, map XML responses and faults, and isolate the legacy interaction behind a reusable workflow or service. New designs should avoid introducing SOAP dependencies unless the business requirement requires them.
Implementation sequence
Common Oracle Eloqua Marketing Automation integration patterns
Pattern 1: Synchronize CRM Contacts and Accounts with Eloqua
When to use this pattern
Use this pattern when Salesforce or Microsoft Dynamics 365 is the operational source for customer and prospect data while Eloqua manages marketing engagement. It supports scheduled or event-driven updates and requires clear ownership for identity, consent, and qualification fields.
Integration direction
Example Mapping
| Oracle Eloqua Marketing Automation Field | Canonical Field | Target Field |
|---|---|---|
| Salesforce Contact.Email | contact.email | Eloqua Contact.emailAddress |
| Salesforce Contact.Id | contact.sourceId | Eloqua Contact.externalId |
| Salesforce Account.Name | account.name | Eloqua Account.name |
| Salesforce Contact.HasOptedOutOfEmail | marketing.emailSuppressed | Eloqua Contact.subscriptionStatus |
Martini implementation pattern
A Martini workflow retrieves changed CRM Contacts and Accounts, resolves existing Eloqua identifiers, normalizes fields, and applies consent rules before creating or updating Eloqua objects. Stable correlation keys make retries safe, while invalid fields, permission failures, and throttling are routed through separate error and retry paths.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- scheduled triggers
- error handling
- retry logic
Pattern 2: Send Eloqua Engagement to a CRM
When to use this pattern
Use this pattern when sales teams need Eloqua Contact Activity, campaign responses, email clicks, form submissions, or qualification signals in Salesforce or Microsoft Dynamics 365. Incremental polling is appropriate when the required event is not covered by Eloqua webhook notifications.
Integration direction
Example Mapping
| Oracle Eloqua Marketing Automation Field | Canonical Field | Target Field |
|---|---|---|
| Contact Activity.contactId | engagement.contactId | Salesforce Contact.Id |
| Contact Activity.activityType | engagement.type | Salesforce CampaignMember.Status |
| Contact Activity.activityDate | engagement.occurredAt | Salesforce Task.ActivityDate |
| Campaign.id | campaign.sourceId | Salesforce Campaign.External_Id__c |
Martini implementation pattern
Martini retrieves activity incrementally using documented identifiers, timestamps, or filters, applies an overlap window, and deduplicates by Contact, activity type, and event time. The workflow transforms engagement into the target CRM model, writes only approved activity, and stores the checkpoint after successful processing.
Martini capabilities used
- scheduled workflows
- API consumption
- incremental synchronization
- data transformation
- deduplication
- checkpoint management
- error handling
Pattern 3: Export Eloqua Data to Snowflake
When to use this pattern
Use this pattern for initial migrations, nightly audience exports, historical activity extraction, analytics, attribution, and reconciliation. Bulk APIs are preferred when the volume makes one REST request per object inefficient.
Integration direction
Example Mapping
| Oracle Eloqua Marketing Automation Field | Canonical Field | Target Field |
|---|---|---|
| Contact.id | eloqua_contact_id | SNOWFLAKE.CONTACTS.ELOQUA_CONTACT_ID |
| Contact.emailAddress | contact_email | SNOWFLAKE.CONTACTS.EMAIL |
| Account.name | account_name | SNOWFLAKE.ACCOUNTS.NAME |
| Contact Activity.activityDate | activity_occurred_at | SNOWFLAKE.CONTACT_ACTIVITY.OCCURRED_AT |
Martini implementation pattern
A scheduled Martini workflow submits an Eloqua Bulk API job, polls until completion, retrieves successful and failed rows, validates schemas, and loads transformed batches into Snowflake. It records job identifiers, source checkpoints, row-level rejects, and retry state so a failed batch does not require repeating completed work.
Martini capabilities used
- scheduler triggers
- workflow orchestration
- Bulk API consumption
- batch processing
- data mapping
- database integration
- monitoring and error handling
Pattern 4: Process Supported Eloqua Webhook Events
When to use this pattern
Use this pattern for Eloqua events covered by its webhook functionality when downstream processing should begin near real time. Because event coverage is selective, unsupported events should use scheduled polling or Bulk API extraction.
Integration direction
Example Mapping
| Oracle Eloqua Marketing Automation Field | Canonical Field | Target Field |
|---|---|---|
| Webhook.resourceId | source.resourceId | ServiceNow.correlation_id |
| Webhook.eventType | event.type | ServiceNow.category |
| Contact.emailAddress | contact.email | ServiceNow.description |
| Campaign.id | campaign.sourceId | ServiceNow.u_eloqua_campaign |
Martini implementation pattern
A Martini API receives and validates the notification, checks for duplicates, and retrieves the current Eloqua object when the notification is only a trigger. Business rules determine whether to create or update a ServiceNow item; downstream work can be asynchronous, with transient failures retried and unsupported events redirected to polling.
Martini capabilities used
- API exposure
- webhook consumption
- workflow orchestration
- data mapping
- business rules
- idempotency
- asynchronous processing
- error handling
Applications commonly integrated with Oracle Eloqua Marketing Automation
Oracle Eloqua is commonly placed in a broader marketing, CRM, data, and enterprise workflow architecture. The exact objects, direction, and event coverage should be confirmed for each customer environment; Martini can orchestrate the APIs, transformations, checkpoints, and business rules between Eloqua and these named applications.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize Contacts, Accounts, campaign membership, lead qualification, and marketing engagement data between Eloqua and Salesforce. | Salesforce → Martini → Oracle Eloqua Marketing Automation | Use REST API workflows for bidirectional synchronization, correlate records with stable identifiers, apply consent and system-of-record rules, and retry transient failures without creating duplicate Contacts. |
| Microsoft Dynamics 365 | Align marketing Contacts, Accounts, campaign activity, and sales-readiness information between Eloqua and Dynamics 365. | Microsoft Dynamics 365 → Martini → Oracle Eloqua Marketing Automation | Schedule incremental reads from both systems, map CRM and Eloqua fields into canonical models, apply matching rules, and route rejected or conflicting records for review. |
| Oracle Responsys | Coordinate B2B marketing automation data in Eloqua with broader Oracle marketing activation and customer-engagement processes. | Oracle Eloqua Marketing Automation → Martini → Oracle Responsys | Consume the relevant Eloqua APIs, normalize audience and engagement data, apply Oracle Marketing configuration rules, and deliver only approved fields to Responsys or an intermediary data platform. |
| NetSuite | Connect marketing Contacts, customer or account data, campaign attribution, and downstream revenue information. | NetSuite → Martini → Oracle Eloqua Marketing Automation | Orchestrate API calls in both directions, correlate customer and account identifiers, transform campaign attribution data, and isolate vendor-specific failures from the wider workflow. |
| Snowflake | Centralize Eloqua Contacts, Accounts, campaign data, and activity history for analytics, attribution, and data science. | Oracle Eloqua Marketing Automation → Martini → Snowflake | Submit and monitor Eloqua Bulk API jobs, retrieve completed results, transform activity and object data, load batches into Snowflake, and record checkpoints and rejected rows. |
| Zoom | Associate webinar registration and attendance with Eloqua Contacts and Campaigns for lead nurturing and scoring. | Zoom → Martini → Oracle Eloqua Marketing Automation | Receive or retrieve Zoom registration and attendance data through the available interface, match participants to Eloqua Contacts, and update campaign-related data subject to confirmed event coverage. |
| ON24 | Transfer webinar registrants and attendance activity into Eloqua for campaign follow-up and lead scoring. | ON24 → Martini → Oracle Eloqua Marketing Automation | Consume the selected ON24 data interface, normalize webinar activity, match contacts using defined identifiers, and submit validated updates to Eloqua through its REST or Bulk APIs. |
| ServiceNow | Route qualified marketing requests, campaign-related cases, or operational handoffs to ServiceNow and return selected status data to Eloqua. | Oracle Eloqua Marketing Automation → Martini → ServiceNow | Receive qualifying Eloqua events or poll activity, apply routing and priority rules, create or update ServiceNow items, and send controlled status updates back to Eloqua. |
How to build a Oracle Eloqua Marketing Automation integration in Martini
Objective
Establish the Eloqua integration using the correct site or pod URL and an authentication method appropriate to the environment.
Instructions in Martini
- Configure OAuth 2.0 where supported and use least-privilege permissions and scopes
- Store client secrets, refresh tokens, credentials, and pod-specific settings in environment configuration or secrets management
- Keep OAuth tokens and Contact data out of workflow definitions and logs
Objective
Select a trigger based on volume, latency, and event coverage rather than assuming every Eloqua change produces a notification.
Instructions in Martini
- Use a Martini API endpoint for supported Eloqua webhook-style notifications
- Use scheduled workflows for polling, incremental synchronization, reconciliation, and bulk-job monitoring
- Use REST APIs for transactional work and Bulk APIs for high-volume operations
Objective
Read the current Eloqua resource or activity data with pagination, checkpoints, and appropriate incremental filters.
Instructions in Martini
- Follow paginated REST collections until all required pages are processed
- Persist timestamps, identifiers, overlap windows, or bulk-job IDs for restartable processing
- Retrieve current resource state after a webhook when the notification is not authoritative
Objective
Coordinate API calls, bulk-job lifecycle steps, validation, routing, and downstream writes in a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, target writes, and error paths into clear workflow stages
- Poll asynchronous Bulk API jobs until completion and handle successful and failed results separately
- Use reusable integration logic for common correlation and checkpoint operations
Objective
Convert Eloqua Contacts, Accounts, Campaigns, Emails, Custom Objects, and Contact Activity into target application schemas.
Instructions in Martini
- Map vendor-specific fields into a canonical model before writing to targets where multiple systems are involved
- Normalize identifiers, dates, email values, activity types, and status fields
- Keep Custom Object and custom Contact field mappings configurable where practical
Objective
Apply business controls for consent, subscription status, matching, ownership, and system-of-record decisions before changing data.
Instructions in Martini
- Preserve Eloqua subscription, opt-in, and suppression semantics
- Use stable identifiers and defined matching rules to prevent duplicate Contacts
- Validate required fields and quarantine conflicting or rejected records
Common Oracle Eloqua Marketing Automation data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Contacts | Store prospects and customers, contact fields, email addresses, and marketing preferences for segmentation, nurturing, and synchronization. | Salesforce, Microsoft Dynamics 365, Snowflake, NetSuite | Martini maps Contact fields to canonical models, applies consent and matching rules, persists Eloqua identifiers, and performs idempotent creates or updates. |
| Accounts | Represent organizations associated with Contacts and account-based marketing processes. | Salesforce, Microsoft Dynamics 365, NetSuite, Snowflake | Martini correlates account identifiers, normalizes organization attributes, applies ownership rules, and synchronizes changes through REST or Bulk workflows. |
| Campaigns | Coordinate audiences, activities, campaign steps, attribution, and marketing program execution. | Salesforce, Snowflake, NetSuite, ServiceNow | Martini maps campaign metadata and membership, applies routing or attribution rules, and transfers selected campaign status or engagement information. |
| Emails | Store email content and configuration used in campaigns and outbound marketing. | Oracle Responsys, Snowflake, internal content or analytics services | Martini can retrieve or transform supported email asset data and apply validation before forwarding it to approved downstream systems. |
| Custom Objects | Store organization-specific data structures beyond standard Contacts and Accounts. | Snowflake, Salesforce, internal databases, Microsoft Dynamics 365 | Martini uses configurable mappings, validates customer-specific fields, and isolates schema changes from reusable workflow orchestration. |
| Contact Activity | Capture engagement such as email opens, clicks, form submissions, and campaign responses. | Salesforce, Microsoft Dynamics 365, Snowflake, ServiceNow | Martini extracts activity incrementally or through Bulk jobs, deduplicates by Contact and activity identifiers, and loads target activity models with checkpoints. |
Authentication and security considerations
Authentication and security
OAuth 2.0 is the preferred modern authentication pattern for Oracle Eloqua integrations. OAuth 1.0a and Basic Authentication may remain relevant for selected legacy or deployment-specific scenarios.
- Register and configure the Eloqua application, redirect URI, or client credentials required by the selected OAuth flow.
- Use the correct Eloqua site or pod URL obtained from the authenticated environment rather than hard-coding a regional host.
- Limit user permissions and OAuth scopes to the resources required by the workflow.
- Store client secrets, refresh tokens, passwords, and endpoint configuration in Martini environment configuration or secrets management.
- Do not place credentials or sensitive Contact data in workflow definitions, error payloads, or logs.
Operational considerations for Oracle Eloqua Marketing Automation integrations
Design for reliable operation
Eloqua quotas and rate limits can vary by API, pod, account configuration, and workload. Martini workflows should respect throttling responses and retry-after information, limit update concurrency, and use exponential backoff for transient failures.
- Follow REST pagination and retain restartable synchronization state.
- Use Bulk APIs for large volumes and manage job submission, polling, results, and partial failures explicitly.
- Use stable identifiers, correlation keys, and deduplication rules for idempotent processing.
- Preserve consent, opt-in, and suppression semantics as separate business-controlled fields.
- Validate customer-specific Custom Objects and custom Contact fields as schemas change.
- Treat webhook notifications as triggers to retrieve current state when necessary, and use polling for unsupported events.
- Log correlation IDs, Eloqua identifiers, outcomes, and retry state without exposing tokens or sensitive Contact data.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration orchestration
Scripts and point-to-point integrations can become difficult to govern when authentication, pagination, transformations, consent rules, bulk-job lifecycles, and retries are implemented separately for each interface. Martini provides a workflow-based integration layer for coordinating these concerns across Eloqua and other enterprise systems.
- Orchestrate REST calls, Bulk API jobs, webhook triggers, schedules, and downstream writes in one managed flow.
- Reuse mappings, validation, correlation, and error-handling logic across integrations.
- Apply business rules for consent, system ownership, qualification, and duplicate prevention centrally.
- Expose controlled APIs instead of distributing Eloqua-specific credentials and pod URLs to every consumer.
- Support monitoring, checkpoints, retries, and controlled deployment across environments.
- Extend workflows with custom logic when Eloqua’s data model or a target system requires additional processing.
Frequently asked questions
Oracle Eloqua can be integrated through its REST APIs for Contacts, Accounts, Campaigns, Emails, activities, assets, segments, and Custom Objects; Bulk APIs for high-volume asynchronous operations; and webhook-style notifications for selected events. OAuth 2.0 is the preferred modern authentication approach, while scheduled workflows support polling, reconciliation, and incremental synchronization.
Yes. Martini can consume Eloqua REST and Bulk APIs, receive supported webhook notifications through an exposed API, transform Eloqua data, and orchestrate synchronization with systems such as Salesforce, Microsoft Dynamics 365, Snowflake, NetSuite, and ServiceNow.
No. A dedicated Oracle Eloqua connector is not required. Martini can use Eloqua’s documented REST and Bulk APIs, supported authentication methods, selected webhook mechanisms, and legacy SOAP services where an existing requirement makes SOAP necessary.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Oracle Eloqua. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Oracle, cloud infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary choice for transactional reads and writes, while Bulk APIs are preferred for migrations, large exports, imports, and scheduled high-volume synchronization. Selected webhook notifications can support event-driven processing. Legacy SOAP should generally be reserved for existing operations unavailable through REST or Bulk APIs.
Martini can expose an API endpoint to receive Eloqua webhook-style notifications for selected events or resources. Coverage is not universal, so the required event must be confirmed. Unsupported events should use scheduled polling or Bulk API extraction.
Use Eloqua identifiers, external correlation IDs, documented timestamps or activity identifiers, and a small overlap window for incremental processing. Martini can persist checkpoints, apply matching and consent rules, and use idempotent updates so retries do not create duplicate Contacts or downstream activities.
Yes. Martini can expose a controlled REST API that encapsulates Eloqua REST or Bulk API operations, applies authorization and business rules, normalizes responses, and shields downstream consumers from pod-specific URLs and vendor-specific data structures.
Related Martini documentation
Workflows
Connect Oracle Eloqua with your enterprise systems
Use Martini to build secure, maintainable Oracle Eloqua integrations across REST APIs, Bulk APIs, supported webhook events, scheduled synchronization, and downstream business systems.