[EPIC] Consolidating HTTP/CEL inputs to CEL for simplified data onboarding

# Epic: One integration, one input — consolidate split CEL/HTTPJSON packages onto CEL

**Team:** Security Service Integrations · **Type:** Epic / initiative

## Why this matters

Onboarding an integration should feel like connecting to one thing. For a whole class of our API-based packages it doesn't, and the reason is invisible to the user.

Over the years these integrations were built with two different Elastic Agent inputs, HTTPJSON and CEL. Older data streams landed on HTTPJSON; newer ones were built on CEL. Nobody set out to split them — it's just what accumulated as packages grew and CEL became our default. But because Fleet groups configuration by input, that history leaks straight into the setup experience.

The result, from a user's chair: you go to connect one product, say SentinelOne, and you're asked for the same console URL and API token more than once, in separate input groups. You then have to work out which data streams live under which input and enable them in two places. You're quietly expected to understand that there are two different collection engines behind one integration, each with its own behaviour around pagination, cursors, and retries. None of this has anything to do with the vendor you're connecting to. It's our packaging showing through.

That's a poor first impression, and first impressions are exactly where we lose people. Onboarding is the moment a user decides whether a source is easy or painful. Making them enter credentials twice and reason about internal input types is friction we put there ourselves, and it lands on some of our most-adopted security sources.

## What "good" looks like

You connect the product once. You enter the connection details one time. You pick the data you want in one place. You never learn that "HTTPJSON" and "CEL" exist, because you never have to. The integration is one thing, and it behaves like one thing.

Getting there means folding the HTTPJSON data streams into CEL across the affected packages, making CEL the single input, and retiring HTTPJSON on a clean deprecation path for existing users.

## Why CEL, and why now

CEL is already our default for new work, so we're standardising on where we're going rather than picking a new direction. It also unlocks a real quality dividend: the improvements we keep shipping to CEL — cursor and state persistence, deduplication, better error handling — only benefit CEL streams today. Every package left half on HTTPJSON is a package where those wins don't fully apply, and where we maintain and test two code paths for one vendor. Consolidating collapses that to one.

Doing it now, as a deliberate initiative rather than one-off fixes, means we fix it consistently and explain it once.

## Scope

Every Security Service Integrations package that currently splits collection across HTTPJSON and CEL. Two shapes show up:

- **Different streams on different inputs** — some data streams are CEL, others HTTPJSON, so the same connection gets configured twice. These need the HTTPJSON streams migrated to CEL.
- **Half-finished migrations** — a stream already offers both CEL and HTTPJSON as a choice. These need CEL made the default and HTTPJSON retired.

Out of scope: transports that genuinely aren't API polling. For example, Cortex XDR's `event` stream reads a GCS bucket that Cortex forwards events into — a different mechanism with different credentials that shouldn't fold into CEL. AWS is also excluded for now; it's a large multi-service package with its own patterns and deserves separate treatment.

## The one real risk

The build is the easy part. The hazard is the upgrade. Switching a stream's input type can reset its cursor and cause a gap or a burst of duplicate events right at the cutover. Every package in this epic needs the same discipline: a cursor-continuity plan, tests that prove no gaps and no duplicates across the switch, and a changelog note that tells existing users what to expect. Where HTTPJSON is being removed, it stays working through a documented deprecation window rather than disappearing under people.

## The work

Each package below has its own issue with the specifics. This epic is the why that ties them together.

### Different streams on different inputs
- [ ] SentinelOne — #20286
- [ ] Google Workspace — #14813
- [ ] Cortex XDR (API streams; `event`/GCS excluded) — #20288
- [ ] AlienVault OTX (`ti_otx`) — #20289
- [ ] Microsoft 365 Defender (`m365_defender`) — #20290
- [ ] Microsoft Defender for Endpoint — #20291
- [ ] Cisco Duo — #20292
- [ ] GitHub — #20293
- [ ] Rapid7 InsightVM — #20297
- [ ] Trend Micro Vision One — #20298

### Half-finished migrations (make CEL default, retire HTTPJSON)
- [ ] Cloudflare — #20294
- [ ] Carbon Black Cloud — #20295
- [ ] Mimecast — #20296

## Success

- Every package above presents a single input. Connection details are entered once and streams are chosen in one place.
- No user has to know what HTTPJSON or CEL are to onboard.
- No regression in collected fields, ECS output, or dashboards; upgrades carry over cleanly with no gaps or duplicates.
- One code path per package instead of two, so CEL improvements apply everywhere.