Decision API

Decision API (an interface for profile-level marketing decisions) passes reviewed eligibility, timing and next-action results into an existing channel stack. It separates decision logic from message execution so email, SMS, push and advertising integrations can use consistent customer context without requiring a full migration.

Updated

Get Free List Audit

The problem it removes

A campaign builder can select an audience while a separate trigger selects the same person for another message. If each tool applies its own copy of permission and frequency rules, the results can disagree. An integration that treats every response as permission to send can also miss a newer suppression or a provider compliance issue.

The API provides a common decision boundary. It is useful when operators need to inspect the proposed action and its reason across systems, rather than reverse-engineer several campaign rules after an incident. The value comes from a correct eligibility check and a dependable execution hand-off, not simply from making a successful request.

How it works

  1. Identify the application, profile and intended action that require a decision. Specify which channel system executes it and which source supplies permission and event context.

  2. Read Unified Profile Graph, Live Marketing Status and relevant timeline inputs before selection. Evaluate profile validity, consent, suppression and frequency in the agreed order.

  3. Apply the reviewed planner logic to choose whether to send, wait or suppress. Include the reason needed for a human to understand the result and investigate an unexpected exclusion.

  4. Connect the result to the existing execution interface and inspect what actually happens. A returned recommendation and an accepted message are different observations, so the workflow must verify both at their respective stages.

EngageMKTG decision layer Customer data sources flow into a unified EngageMKTG decision layer, which makes safe one-to-one decisions for lifecycle marketing channels. ONE LIVE DECISION PATH Data in. Explainable action out. CUSTOMER DATA ENGAGEMKTG Decision Layer CHANNELS ESPCRM WebOrders ConsentEvents Unified Profile Live Marketing Status Event Timeline Intelligent Planners Decision API Email SMS Push RTB CRM CUSTOMER DATA ESP · CRM · Web · Orders · Consent · Events ENGAGEMKTG DECISION LAYER Profile → Status → Timeline Planners → Decision API Privacy-aware · Human controlled CHANNEL ACTION Email · SMS · Push · RTB · CRM ↓ Lower CAC↑ Higher CLV ✓ Safer sends1-to-1 decisions

Implementation defines the integration contract for the chosen tools. Confirm how the caller handles an unavailable decision, stale source data and repeated requests before enabling the production flow. A failed check should not become an accidental fallback to sending. These are acceptance conditions to verify with the specific integration, not claims about an undocumented public endpoint.

Keep provider compliance in the operating context. A profile may have valid consent while the sending domain has an authentication problem. The sender requirements tracker explains obligations that should be reviewed alongside individual eligibility. A decision layer cannot make a blocked or misconfigured sending system healthy by returning a positive audience selection.

Record which downstream system acted on the decision so an operator can distinguish a recommendation from an executed message.

Where it shows up

Day-0 Activation combines Zero Day Planner, Lifecycle Stage Trigger and Decision API for onboarding after registration. Lifecycle Decisioning combines Decision API, Intelligent Planners and Data Intelligence Framework for the full decision waterfall. Implementation Services scopes the calling systems and verifies their execution behavior.

What it is not

Decision API is not an ESP or a message-delivery guarantee. It returns decision context to channel tools; it does not replace their transport, authentication, reputation or reporting. It is also not a substitute for consent evidence. Treat a permitted decision, a provider-accepted message, a delivered message and a customer response as separate stages with separate evidence.

FAQ

Do we have to replace our ESP?

No. The API connects decisions to the existing channel stack. Integration scope depends on the interfaces and controls available in your provider and application.

Is the API only for email?

The platform describes email, SMS, push and advertising use cases. The first integration should name the channel, required context and execution responsibilities rather than assuming every connector is already configured.

What happens when a decision cannot be made?

The integration must define a safe outcome for missing or unavailable inputs and verify it before release. An error or absent response must not be interpreted as permission to send.

How do we evaluate the result?

Inspect the action and reason, then verify the channel workflow respects it. Measure decision errors and subsequent customer outcomes against the agreed baseline; request success alone is insufficient.

Read more

Read Postmaster Tools v2 for compliance inputs and playbook Step 7: stop conditions before defining release behavior.

Read before you start