Marketing Automation
Adobe Marketo Engage
Rest of world Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Adobe Inc. · business.adobe.com
Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
The bench judged from captured developer documentation: an asynchronous data-ingestion API and journey capping and throttling configuration. Strongest is CRM and data at 4-6: upserts for persons, companies, custom objects, program members and lists, deduplication on declared keys including email and Salesforce identifiers, a 65-minute retry window for custom objects linked to a missing person, and request status through the Marketo Observability Data Stream. Scores spread 4 to 6 there — two judges reached 6 on the documented API's depth, while the others held at 4 on the one-way direction, with no public information on bidirectional CRM sync, field mapping or conflict resolution. Journey orchestration scores 2-4: real rate governance for external calls, but the capping governs calls to endpoints, not how often a person is contacted, and no public information on branching, waits or per-contact journey state. Lead management sits at 1-2 on program statuses and static lists alone. Channel coverage and consent and profiling score 0-1; sovereignty scores 0 with no sovereignty attributes on record. Pricing transparency scores 0 — the captured pages are developer references containing no prices.
Speaks for it
- Asynchronous ingestion API upserts persons, companies, custom objects, program members and lists
- Deduplication runs on declared keys including email, internal ID, Salesforce identifiers and custom string or integer attributes
- Custom-object upserts retry for 65 minutes when the linked person does not yet exist
- Request status is retrievable through the Marketo Observability Data Stream
- Journey capping and throttling configurations carry deploy, undeploy and pre-deployment canDeploy validation
Held against it
- The evidenced data flow is one-way, with no public information on bidirectional CRM sync, field mapping or conflict resolution
- We found no public information on lead scoring, lifecycle stages or routing; the evidenced mechanics are program membership statuses and static lists
- The captured pages name no send channel, email included, with no public information on dynamic content or shared suppression
- For named-person profiles we found no public information on consent capture, retention rules or per-contact tracking controls
- No sovereignty attributes are on record, and the captured pages state nothing about hosting location or subprocessors
Best for
- You need a documented high-volume API to upsert person, company, custom-object, program-member and list records with rule-based deduplication
- Your journeys call external systems and you need per-endpoint call caps and organisation-level throughput limits validated before deployment
- You run Salesforce and want ingestion keyed on Salesforce identifiers such as sfdcContactId
Avoid if
- You need documented lead scoring and routing to owners; the evidenced lifecycle material covers only program membership statuses and static lists
- You require bidirectional CRM sync with field-level conflict rules; the captured evidence covers one-way ingestion
- You must review consent capture and per-contact tracking controls before processing profiles of named people; consent and profiling scored 0-1
The scores
Journeys & orchestration
Show reasoningHide reasoning
How this is scored
Multi-step automation: triggers, branching, waits, and — the part that decides whether it survives contact with reality — what happens when journeys collide.
0 — Autoresponders on a single trigger; no branching, no waits, no conditions.
3 — Linear sequences with simple conditions, one entry trigger per journey, and no visibility into where a contact currently sits.
5 — A visual builder with branching on attributes and behaviour, waits and goals, entry and exit conditions, and per-contact journey state visible.
8 — Event-driven entry from external systems, frequency capping and suppression across journeys, priority when a contact qualifies for several, versioning of a live journey, and testing against real records.
10 — Orchestration is coherent across the whole programme: one decision layer deciding what a person receives next regardless of which journey wants to send it, holdout groups for measurement, and a journey a colleague can read months later without a diagram.
The Demand Gen Lead
The captured pages document a real orchestration perimeter — journeys integrating with external systems, capping and throttling configurations with deploy and undeploy states, canDeploy validation and organisation-level throughput limits — but the capping governs outbound API calls to endpoints, not how often a person is messaged. We found no public information on branching, waits, per-contact journey state, or arbitration when several journeys want the same person. Solid plumbing, no evidence of the decision layer. 1
The Sales Ops Manager
The captured developer pages show a journey orchestration layer with organisation-level throughput caps, per-endpoint call limits for actions and data sources, pre-deployment validation and virtual sandbox isolation — evidence of event-driven journeys reaching into external systems. I found no public information on branching, waits, goals, per-contact journey state, or suppression and priority when a person qualifies for several journeys, which keeps this mid-scale. 1
The Data Protection Officer
What the captured pages document is a set of capping and throttling configuration APIs governing how often journeys may call external endpoints, with deployment states and pre-deploy validation — infrastructure, not orchestration of what a person receives. We found no public information on branching, waits, entry and exit conditions, per-contact journey state, suppression across journeys or versioning of a live journey. 1
The Lifecycle Marketer
The captured developer pages show genuine orchestration machinery around external systems — capping and throttling configurations with validation, deployment states and a single organization-level throttling rule — but what is capped is API call volume to endpoints, not how often a person is contacted. We found no public information on branching, waits, entry and exit conditions, per-contact journey state, cross-journey suppression or holdout groups. I score what is evidenced: real rate governance for external calls, and no evidenced person-facing journey model. 1
The Solution Architect
The captured pages show journeys only from the outside: capping and throttling configurations with deploy, undeploy and canDeploy validation, one throttling configuration allowed per organisation, and custom actions plus external data sources as first-class concepts. That is plumbing for external-system integration — and note the capping caps calls to external endpoints, not message frequency to a person. I found no public information on the builder itself: branching, waits, per-contact journey state, or arbitration when several journeys want the same contact. 1
The Skeptic
The captured developer pages document capping and throttling for journeys — per-endpoint call caps, one organisation-wide throughput configuration, and a deploy/undeploy lifecycle with pre-deployment validation — which is real rate governance around the journey engine. What they never show is the staircase itself: I found no public information on branching, waits, entry and exit conditions, or where a contact currently sits in a journey. Plumbing without evidenced mechanics. 1
Lead scoring, routing & lifecycle
Show reasoningHide reasoning
How this is scored
Scoring, qualification and handover to sales — including whether the customer can explain to a lead why the system decided what it decided.
0 — No scoring or lifecycle model; every contact is treated alike.
3 — A single additive score with fixed rules, no decay, no lifecycle stages and no routing.
5 — Configurable scoring on attributes and behaviour with decay, lifecycle stages, and routing to owners or teams with notification.
8 — Multiple scoring models per product or region, negative scoring, account-level scoring alongside contact-level, SLA on follow-up, and score history visible per contact.
10 — Scoring is explainable and accountable: the contribution of each signal visible per record, model changes versioned with their effect on the funnel, routing rules auditable, and predictive scoring — where offered — documented well enough for a DPO to assess it as automated decision-making.
The Demand Gen Lead
What the captured pages show is lead records, static lists and program membership statuses — lifecycle inside a program, not a lifecycle for a lead. We found no public information on scoring models, decay, negative scoring, routing to owners or sales handover with notification. A pipeline review cannot run on membership statuses alone. 2
The Sales Ops Manager
The captured pages show only program membership status management and static list add/remove; I found no public information on scoring, decay, lifecycle stages or routing to owners. Program member statuses are the one lifecycle-adjacent feature evidenced, and that is a campaign view, not a lead lifecycle. 2
The Data Protection Officer
The documentation covers persons, program membership status and static lists, but we found no public information on any scoring model, decay, lifecycle stages beyond program membership, qualification or routing to owners. Without a documented score there is nothing to show a lead, and nothing for me to assess as an automated decision. 2
The Lifecycle Marketer
We found no public information on lead scoring, score decay, lifecycle stages or routing to owners; the only lifecycle-adjacent material is program member status handling and adding or removing leads from static lists. Without scores, qualification logic or any explainability of why a person was treated as they were, this sits at the bottom of the range. 2
The Solution Architect
I found no public information on lead scoring, decay, lifecycle stages, negative scoring, or routing to owners and teams. The only adjacent capability is program membership status sync and program member removal — a campaign artefact, not a lifecycle model a sales team could hand over against. With no evidence of scoring at all, this sits at the bottom. 2
The Skeptic
The only lifecycle-adjacent mechanics evidenced are program-membership status upserts and adding or removing leads from static lists. I found no public information on scoring of any kind — additive, decaying or predictive — on qualification, or on routing and handover to sales. Program statuses are not a scoring model. 2
Channels & personalisation
Show reasoningHide reasoning
How this is scored
What the platform can actually send and personalise: email, SMS, push, on-site content, ads audiences — judged on what shares one profile and one suppression list.
0 — Email only.
3 — Email plus one further channel, managed separately with its own list and no shared suppression.
5 — Email, SMS or push and web forms driven from one contact profile, with dynamic content blocks and shared unsubscribe handling.
8 — The above plus on-site personalisation, ad-audience sync to the major networks, cross-channel frequency capping, and content personalised on behaviour rather than only on stored fields.
10 — Channel is a delivery detail: one profile and one consent state across every channel, next-best-channel selection, and personalisation that draws on the full behavioural record without the marketer assembling it by hand.
The Demand Gen Lead
The captured pages are API references for data ingestion and journey throttling, and they name no channel — nothing on email, SMS, push, on-site content or ad audiences appears in what we reviewed. We found no public information on personalisation, dynamic content or shared suppression either. On that absence this sits at the floor. 1 2
The Sales Ops Manager
The captured pages document data ingestion and journey governance but name no messaging channel — I found no public information on email, SMS, push, on-site content or ad audiences, let alone shared profiles or suppression across them. Journeys imply delivery of something, but the pages never say what. 1 2
The Data Protection Officer
The captured pages cover data ingestion and journey API configuration only, and we found no public information on email, SMS, push, on-site personalisation, ad-audience sync, or a shared suppression list across channels. 1 2
The Lifecycle Marketer
We found no public information on send channels, dynamic content or shared suppression in the captured pages: nothing on email, SMS, push, on-site personalisation or ad-audience sync, let alone one profile and one consent state across them. Absent any channel evidence, the floor is what the evidence supports. 1 2
The Solution Architect
The captured pages document data ingestion only; I found no public information on email, SMS, push, on-site content or ad-audience sync, nor on any shared suppression list across channels. I cannot evidence even an email baseline from what was published, so there is nothing here to score. 2
The Skeptic
The captured pages describe ingestion of person and person-related data and capping of external endpoints, and that is all. I found no public information on any send channel — email included — on dynamic content, or on shared suppression handling, so a channel question with nothing evidenced sits at the floor. 1 2
Consent, tracking & profiling
Show reasoningHide reasoning
How this is scored
The platform builds behavioural profiles of named people. Consent capture and proof, tracking that can be limited, retention, and whether automated decisions about individuals are documented and contestable.
0 — Tracking always on and undocumented, single opt-in, no consent record, no retention rule, no way to exclude a person from profiling.
3 — Double opt-in available with a timestamp, cookie tracking that cannot be disabled per contact, and retention described as the customer's problem.
5 — Double opt-in as documented default with a stored consent record including source, per-channel consent states, tracking switchable per contact, and stated retention for inactive records.
8 — Consent reproducible as evidence with the wording versioned, profiling suppressible per person, retention executed per data category, documented handling of access and erasure requests including derived scores, and a cookieless or first-party tracking mode.
10 — Built for the accountability principle: a per-contact history of what was tracked, scored and decided, automated decision-making documented well enough to support an Art. 22 assessment, profiling off by default for anyone who has not consented to it, and deletion that removes derived scores as well as raw events.
The Demand Gen Lead
The single tracking-adjacent item captured is the Munchkin subscription identifier; we found no public information on consent capture, stored consent records with source, per-channel consent states, retention rules for inactive records, or suppression of profiling per person. For a platform whose product is behavioural profiles of named people, that silence is decisive. 2
The Sales Ops Manager
Person records, person partitions and web-tracking subscription identifiers appear in the API pages, so behavioural profiling of named people is clearly in scope. I found no public information on consent capture, per-contact tracking switches, retention rules, or handling of access and erasure requests — for a platform holding these profiles, that silence is itself the finding. 2
The Data Protection Officer
These APIs ingest person, company and custom-object records on named individuals at high volume and minimal latency, yet we found no public information on consent capture, a stored consent record with source, per-channel consent states, limiting tracking per person, retention rules per data category, or access and erasure handling including derived scores. For a platform whose documented purpose is to ingest behavioural data on named people, I treat that silence as decisive. 1 2
The Lifecycle Marketer
We found no public information on consent capture, per-channel consent states, stored consent records, per-contact tracking controls or retention for inactive records. For a platform that ingests person and person-related data on named individuals, the complete absence of consent and profiling governance decides this. 2
The Solution Architect
For a platform ingesting named persons and person-related data, I found no public information on consent capture, double opt-in, per-channel consent states, tracking switches, retention rules, or suppression of profiling for an individual. No sovereignty attributes are on record either, which leaves the accountability picture entirely unevidenced in these pages. 1 2
The Skeptic
Person records are upserted with email as a deduplication key, so named profiles are plainly the operating model. Yet I found no public information on consent capture or a stored consent record, on limiting tracking per contact, on retention, or on suppressing anyone from profiling. Silence on every one of those, for a platform whose premise is profiles of named people, scores at the floor. 2
CRM integration & data model
Show reasoningHide reasoning
How this is scored
The join that decides the implementation: how the platform and the CRM stay in agreement about who a person is, and what happens when they disagree.
0 — CSV import and export; no CRM integration and no identity resolution.
3 — One-way sync into a named CRM on a schedule, with duplicates resolved by hand and no conflict rules.
5 — Bidirectional sync with at least one major CRM, field mapping, deduplication rules, and a sync error log somebody can act on.
8 — Configurable conflict resolution per field, account and contact objects both modelled, custom objects supported, near-real-time sync with retry, and a documented API with rate limits.
10 — One record, two systems, no ambiguity: identity resolution across anonymous and known states, field-level ownership defined per system, replay of failed syncs, and a data model the customer can extend without vendor services.
The Demand Gen Lead
The ingestion API is the strongest thing here: persons, companies, custom objects, program members and lists, upsert semantics, deduplication on multiple keys including Salesforce identifiers, a 65-minute retry window for custom-object links, person partitions, and request status through the observability stream. The evidenced direction is one-way into Marketo; we found no public information on bidirectional CRM sync, field mapping or per-field conflict resolution. Strong data model, unproven two-way join. 1 2
The Sales Ops Manager
This is the best-evidenced area: documented upsert for persons, companies, custom objects and program members, deduplication by declared fields including Salesforce identifiers and custom attributes, a 65-minute retry window when a linked person is missing, and request status retrievable through an observability stream alongside a published API specification. What I found no public information on is per-field conflict rules, field mapping, and a bidirectional sync with a named CRM — upsert semantics are not conflict resolution, and I inherit every record that ambiguity creates. 2
The Data Protection Officer
The ingestion API documents asynchronous upserts of persons, companies, custom objects and program members with rule-based deduplication on named attributes including Salesforce identifiers, a 65-minute retry window for records linked to a not-yet-existing person, and request status retrievable through the Observability Data Stream. We found no public information on bidirectional sync with a CRM, field mapping, per-field conflict resolution, or documented rate limits. 2
The Lifecycle Marketer
One-way ingestion is real and well-tooled: upserts for persons, companies, custom objects and program members, deduplication on declared keys including email and Salesforce identifiers, a 65-minute retry window for custom objects linked to a missing person, and request status retrievable through the observability stream. The two-way question stays open — we found no public information on sync back to a CRM, field mapping, conflict rules or field ownership when the systems disagree. Automated dedupe on named keys plus a documented API with a downloadable specification puts this above a plain one-way import but short of a bidirectional join. 2
The Solution Architect
This is where the pages have substance: a documented async ingestion API covering Persons, Companies, Program Members, Lists and custom objects, with dedupe attributes including native Salesforce identifiers and request status traceable through an observability data stream — and the custom object upsert that retries for 65 minutes when a linked Person does not yet exist is exactly the detail that survives real implementations. What I did not find: bidirectional CRM sync, field mapping, per-field conflict rules, Marketo's own inbound rate limits, or any documented path from anonymous visitor to known contact. Custom objects are extendable through the documented API without vendor services, which counts for a lot, but identity resolution is the join I actually need and it stays unevidenced. 1 2
The Skeptic
The async ingestion API upserts persons, companies, custom objects, program members and lists with deduplication rules keyed on email, internal ID or Salesforce identifiers, a 65-minute retry window when a linked person is missing, and request status retrievable through an observability data stream — duplicates resolved by rule, errors somebody can act on. What I did not find is public information on bidirectional sync, field mapping, or what happens when the two systems disagree about a record. Strong one-way plumbing with account and contact objects both modelled, short of the bidirectional join that decides an implementation. 2
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where behavioural profiles of named EU residents are processed, who the contracting entity is, and which subprocessors see them. Independently sourced by the sovereignty pipeline; scored here as this buyer weighs it — which given the profiling is heavily.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed, behavioural data leaving the EU with no stated basis.
3 — EU data residency for storage while tracking, sending or support access remain non-EU, or the contracting entity sits outside the EU.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — tracking scripts, AI scoring, analytics — are non-EU without an explained safeguard.
8 — EU hosting on named infrastructure, EU contracting entity, complete subprocessor list published, and any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: every profile, event and derived score processed in the EU by European subprocessors, certification published, and no transfer requiring a Schrems II argument to survive.
The Demand Gen Lead
The contracting party is Adobe Inc. of San Jose, California, and the captured developer pages state nothing about hosting location, EU data residency or subprocessors. We found no public information on any European processing arrangement for profiles, events or derived scores. With behavioural profiles of EU residents in scope, that is the floor. 1 2
The Sales Ops Manager
The contracting entity is Adobe Inc. of San Jose, California, and the captured material states no hosting location, names no subprocessors and gives no legal basis for transfers of behavioural profile data out of the EU. With profiling of named residents at stake and no sovereignty attributes on record, this sits at the floor. 1 2
The Data Protection Officer
The vendor on record is Adobe Inc. of San Jose, California, with no sovereignty attributes on record, and the captured pages state nothing about EU hosting, an EU contracting entity, subprocessors, or a legal basis for transferring the behavioural data these APIs process. Behavioural profiles of EU residents with no stated safeguards are, for this buyer, the lowest case. 1 2
The Lifecycle Marketer
The vendor is Adobe Inc., San Jose, California, and no sovereignty attributes are on record: we found no public information on EU hosting, an EU contracting entity, a subprocessor list, or any stated basis for processing behavioural data outside the EU. For a platform ingesting person and person-related data on named individuals, that weighs as heavily as it reads. 2
The Solution Architect
The contracting entity is a US vendor headquartered in San Jose, and I found no public information on hosting location, subprocessors, certification, or any legal basis for EU behavioural data being processed outside the EU. With no sovereignty attributes on record and the documented APIs served from Adobe's platform gateway, this weighs at the bottom for a buyer holding profiles of named EU residents. 1 2
The Skeptic
The vendor of record is Adobe Inc. of San Jose, California, and the captured pages state nothing about where profiles are processed, which entity contracts, or which subprocessors see the data — we found no public information on any of it, let alone a safeguard for behavioural profiles of EU residents. This buyer weighs sovereignty heavily, and there is nothing here to weigh. 1 2
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the real annual invoice for their contact base and send volume — including the tier where automation actually begins, overage, and mandatory onboarding — from public pages alone.
0 — No public prices at all; every tier is a sales conversation, and onboarding fees are never mentioned.
3 — A contact-tier headline exists, but the tier where journeys, scoring or CRM sync begin is unstated, as is any mandatory implementation fee.
5 — Contact-tier prices public with billing period and send limits stated, but at least one commonly needed capability sits in an unpriced enterprise tier.
8 — Every tier priced publicly with contact and volume limits, feature boundaries, overage rates, onboarding costs, minimum term and VAT treatment stated.
10 — Complete price computability: annual invoice derivable for a given contact count, send volume and feature set, including overage, additional users and any implementation fee stated outright.
The Demand Gen Lead
The captured pages are API documentation with no tier, price, contact limit, send volume, overage rate, minimum term or onboarding fee in them. We found no public information from which a buyer could compute an annual invoice for a contact base and send volume. That is the floor. 1 2
The Sales Ops Manager
I found no public pricing at all in the captured material — no contact tier, no send limits, no statement of where automation begins and no mention of onboarding fees. A buyer cannot begin to compute an annual invoice from what is published here. 1 2
The Data Protection Officer
Both captured pages are developer references containing no prices, and we found no public information on contact tiers, where automation capabilities begin, send limits, overage, onboarding fees, minimum term or VAT treatment. 1 2
The Lifecycle Marketer
We found no public information on pricing in the captured pages: no contact tiers, send limits, overage rates, onboarding fees, or indication of where automation capabilities begin. There is nothing here from which a buyer could compute an annual invoice. 1 2
The Solution Architect
I found no public information on pricing anywhere in the captured pages: no tiers, no contact or send limits, no feature boundaries by tier, no overage rates, and no mention of onboarding costs, minimum term or VAT treatment. A buyer can compute nothing from this. 1 2
The Skeptic
The captured pages are developer documentation end to end: we found no public information on prices, contact tiers, send limits or overage rates, and none on any mandatory onboarding or implementation fee — the one that never appears on a pricing page. Nothing here lets a buyer compute even the first line of an annual invoice. 1 2
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 1 Oct 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- We found no public information on pricing on the pages we read (developer.adobe.com/journey-optimizer-apis/references/journeys-throttling, developer.adobe.com/marketo-apis/api/data-ingestion). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- We found no public information on compliance on the pages we read (developer.adobe.com/journey-optimizer-apis/references/journeys-throttling, developer.adobe.com/marketo-apis/api/data-ingestion). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
Sources (2)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Journeys & orchestration — found from sitemap developer.adobe.com Checked 1 Oct 2026 Details →
- 2 CRM integration & data model — found from sitemap developer.adobe.com Checked 1 Oct 2026 Details →