Is this just CAPTCHA for Eloqua forms?

No. It is a managed marketing-operations protection layer that combines Turnstile verification, server-side Worker validation, review workflow, safe forwarding, and reporting.

Does the public page expose the dashboard?

No. Client dashboards are protected, client-specific workspaces. Public pages describe the capability without exposing private URLs, tokens, credentials, or internal routes.

Is AI used in the first version?

The first version is deterministic and rules-based. AI-assisted scoring, spam memory, campaign-fit checks, and reporting are planned future layers.

Where are suspicious submissions held before review?

Suspicious or failed submissions can be stored in Cloudflare KV as a pending review queue or rejected spam evidence, keeping them out of Eloqua until a routing or review decision is made.

Is the product ISO certified?

The product is built on Cloudflare infrastructure with recognised security and compliance coverage, but pl8ypus does not claim ISO certification for this product today. The architecture is designed to support enterprise security review through protected access, clear data flow, controlled storage, retention rules, and documented review workflows.

Managed Eloqua protection

Marketing Form Protection for Eloqua

Q: What role does Cloudflare KV play?

Cloudflare KV acts as the operational datastore for pending review records, rejected spam evidence, form routing configuration, and future client-specific spam memory. This helps keep suspicious submissions out of Eloqua until a routing or review decision is made.

Stop spam, bot submissions, and fake leads before they pollute Oracle Eloqua - with Turnstile verification, Worker validation, protected review, and safe forwarding.

Not just CAPTCHA. A managed protection layer for Eloqua form data quality.

Explore how it works

Managed protection layer

Build status

Pilot-ready

Turnstile + Worker + KV

Review mode

Protected queue

Routing

Pass / hold / reject

Storage

Cloudflare KV

Destination

Oracle Eloqua

Routing strip

Clean forward

Suspicious hold

Rejected retain evidence

Illustrative UI only. Client dashboards are protected and client-specific.

01

Eloqua form

02

Turnstile

03

Cloudflare Worker

04

Review dashboard

05

Safe Eloqua forwarding

Solution architecture

How the protection layer fits together

The architecture uses Cloudflare Turnstile for front-end verification, a Cloudflare Worker for server-side validation and routing, Cloudflare KV for review queues and spam evidence, and a protected dashboard for client review before accepted records are safely forwarded into Oracle Eloqua.

Cloudflare KV acts as the lightweight operational datastore for the protection layer. It can hold pending review records, rejected spam evidence, routing configuration, and future client-specific spam memory.

Cloudflare KV gives the protection layer somewhere safe to hold suspicious records before they touch Eloqua. Clean submissions can be forwarded directly, while failed or suspicious submissions can be stored for review, accepted, rejected, or retained as evidence.

Architecture preview - click to enlarge

Includes Cloudflare KV

Illustrative solution view for the managed protection layer.

Security and compliance foundation

Built on Cloudflare. Designed for enterprise review.

The protection layer is built on Cloudflare services with recognised security and compliance coverage. Turnstile handles front-end verification, Workers handle server-side validation and routing, KV stores operational review and evidence records, and Cloudflare Access can protect client dashboards.

Cloudflare provides the infrastructure compliance foundation. pl8ypus then adds the product implementation controls: access model, review workflow, retention rules, decision logging, and safe forwarding into Oracle Eloqua.

This does not mean pl8ypus is claiming ISO certification today. It means the architecture is designed to be enterprise-review friendly, with a clear data flow, protected access, controlled storage, and documented operational responsibilities.

Compliance-ready building blocks

Cloudflare-backed foundation

Cloudflare Turnstile

Front-end verification before a form submission is trusted.

Cloudflare Workers

Server-side token validation, routing logic, and forwarding decisions.

Cloudflare KV

Operational storage for pending review records, rejected spam evidence, routing configuration, and future spam memory.

Cloudflare Access

Protected dashboard access for authorised client users.

Oracle Eloqua forwarding

Accepted records are forwarded only after the defined validation and routing logic has run.

pl8ypus controls

Retention, review workflow, decision logging, onboarding, and client-specific operating rules.

KV should be treated as an operational review and evidence store, not the long-term system of record. Oracle Eloqua remains the destination for accepted marketing submissions.

AI-assisted scoring is not part of the compliance claim today. The current compliance story is based on deterministic Turnstile, Worker, KV, Access, and Eloqua forwarding architecture.

The problem

Eloqua form spam damages the campaign workflow.

Once bot submissions and fake leads enter Eloqua, they distort reporting, waste sales follow-up, trigger manual cleanup, and make form performance harder to trust. The same spam patterns can appear across campaigns, regions, and landing pages, leaving teams to fix data quality after the damage has reached the platform.

The solution

A managed review layer before data reaches Eloqua.

This is not just CAPTCHA. It is a marketing-operations protection layer designed around validation, routing, review, and safe handoff into the right Eloqua form.

The first implementation is focused on Oracle Eloqua. The same architecture can later support other marketing forms where data quality, protected review, and campaign-level visibility matter.

Cloudflare KV stores the pending review queue, rejected spam evidence, form routing configuration, and client-specific spam memory. This keeps suspicious data out of Eloqua while still giving the client a controlled review and audit trail.

After protection

Clean submissions forward safely

Suspicious submissions held

Rejected records retained as evidence

Campaign data stays cleaner

Review decisions become visible

Workflow

How the protection layer works

01

Protect the form

Apply the managed layer to selected Eloqua forms and campaign pages.

02

Verify with Cloudflare Turnstile

Confirm the interaction before the submission can continue.

03

Validate server-side in the Worker

Check the verification response and route the record through controlled logic.

04

Route suspicious records

Hold risky or failed submissions outside Eloqua for review.

05

Review, approve, or reject

Give authorised users a protected queue for campaign-safe decisions.

06

Forward clean data to Eloqua and report patterns

Approved records reach the right form. Rejected patterns become evidence for reporting.

Future layer

Built for AI-assisted review

The first version is deterministic and rules-based: Turnstile verification, Worker validation, review queue, and safe Eloqua forwarding. The future layer adds AI-assisted scoring for suspicious submissions, lead-quality checks, spam-pattern detection, and campaign-level reporting.

Cloudflare AI is the natural future layer for this workflow, but AI is planned as an assistant to review and reporting. It is not the first line of defence.

Over time, the KV-backed review history can become the foundation for client-specific spam memory and future AI-assisted scoring.

Future AI signals

Planned layer

Message quality score

82/100

Fake lead likelihood

Medium

Campaign-fit signal

Review

Repeated pattern match

Detected

Client-specific spam memory

Monthly summary generation

AI assists review. Turnstile and server-side validation remain the foundation.

Protected client area

Client-specific dashboards, not public demos.

Each client can have a protected dashboard in the pl8ypus client area for form review, accepted and rejected submissions, form-level routing, monthly reporting, and a campaign protection view.

Example workspace names might include Solventum Form Protection or Hitachi Energy Form Protection. These are examples of client-specific naming only, not claims of a live commercial contract.

View client area context

Protected workspace

Solventum Form Protection

Client login

Queue Accepted Rejected Forms Reports

Pending review queue

12 pending

Accepted/rejected submissions

321 decisions

Hitachi Energy Form Protection

Example label

Pilot packages

Indicative packages for controlled rollout.

Pricing is guidance for pilots and managed packages, not fixed public pricing.

Starter Pilot

From £295/month

For one campaign or proof of value.

1 protected Eloqua form

Turnstile verification

Basic review workflow

Monthly summary

Recommended pilot

Managed Protection

From £750/month

For active marketing teams.

Up to 5 protected forms

Protected dashboard

Accept/reject forwarding

Form-level routing

Monthly reporting

Client Pro

From £1,250/month

For larger Eloqua teams.

Multi-form support

Client-specific dashboard

Advanced routing rules

Campaign launch support

Enterprise

Custom

For regional, multi-brand, or heavily governed teams.

Custom access control

Wider reporting

Governance support

Advanced implementation

Pricing depends on form volume, number of Eloqua forms, dashboard requirements, reporting needs, and support model. Pilot setup and implementation scope are quoted separately depending on the number of forms, Eloqua complexity, routing rules, and review requirements.

Why pl8ypus

Why this belongs with pl8ypus

This sits at the intersection of Eloqua implementation, Cloudflare Workers, protected client apps, and marketing data quality.

Eloqua-first implementation knowledge

Form routing and campaign handoff context

Practical marketing automation constraints

Data quality before lead follow-up

Cloudflare-native product architecture

Worker validation and routing patterns

Protected app thinking from the start

Safe public pages with private operations

Marketing operations workflow thinking

Review queues that match real team behaviour

Reporting built around campaign confidence

Rollout paths from pilot to managed service