Skip to main content
POST

Rate Limit

The rate limit is 100 requests per minute, 300 requests per hour, and 600 requests per day per consumer.

Authorizations

Authorization
string
header
required

Authentication is done via Basic Auth. This requires a base64-encoded string of your credentials in the format 'username:password'.

  • Username: Use your MoEngage Workspace ID (also known as the App ID). Find it in the dashboard at Settings > Account > APIs > Workspace ID (earlier app id).
  • Password: On your MoEngage workspace, navigate to Settings > Account > API keys. Use the Key listed within the Personalize tile.

For more information on authentication and getting your credentials, refer to Getting your credentials. Send the value in the Authorization header as Basic followed by Base64-encoding of appkey:apisecret (workspace ID and API key).

Headers

Idempotency-Key
string<uuid>
required

UUID v4 idempotency token. Submitting the same key within 24 hours returns the original 201 response without re-creating the Offering. A different body hash on the same key returns 409 IDEMPOTENCY_CONFLICT. A concurrent in-progress request with the same key returns 409 DUPLICATE_IDEMPOTENCY_KEY.

X-MOE-Request-Id
string<uuid>

Client-supplied trace ID (UUID v4). Echoed back in the X-MOE-Request-Id response header. Use this to correlate client requests with server-side logs.

Body

application/json

Request body for creating an Offering via POST /v5/offers.

Required fields: name, priority, delivery, created_by, scheduling, segment_info, offer_content, variation_meta.

name
string
required

Unique display name for this offering within the workspace. Names are case-sensitive and must be unique. Allowed characters: alphanumeric characters and underscores (_).

Required string length: 5 - 100
Example:

"Summer_Sale_Promo_2026"

priority
integer
required

Static priority score for offer ranking. Lower number means lower priority (1 is lowest priority, 100 is highest). This score is used when the Decision Policy ranking strategy is set to Offering Priority.

Required range: 1 <= x <= 100
delivery
enum<string>
required

Controls when the offering is eligible for delivery. scheduled — the offering is served within its scheduling window.

Available options:
scheduled
created_by
string<email>
required

Email address of the user creating this offering.

Example:

"marketing-team@example.com"

scheduling
object
required

Scheduling window that determines when an offering is eligible for delivery. Both start_datetime and expiry_datetime are required when creating an offering.

segment_info
object
required

Segment targeting configuration that controls which users are eligible to receive this offering.

included_filters: criteria a user MUST match to be eligible. excluded_filters: criteria that DISQUALIFY a user even if they match the included filters.

To target all users, send an empty filters object: { "filters": {} }

offer_content
object
required

The core content payload delivered to the end-user. This object supports two mutually exclusive structures depending on whether your offering uses content variations or experimentation.

Mutually Exclusive: Do not provide both content_1 and locales in the same request payload. Doing so will result in a validation error.

1. Flat Format (No Content Variations)

Use this structure for simple offerings that do not require A/B testing or localization.

  • Payload Structure: Send a single content_1 object at the root level.
  • Behavior: The exact same content block is served universally to all eligible users.

2. Nested Format (Multiple Content Variations)

Use this structure when variation_meta.type is configured as either SMV (Static Multi-Variant) or DMV (Dynamic Multi-Variant).

  • Payload Structure: Send a structured locales map object.
  • Single-Locale Targeting: For single-locale offerings, you must use "0" as the literal locale key string.
  • Variations Mapping: Inside each locale, the nested variations map keys must exactly match the variation IDs defined in variation_meta.variantsPerLocale and smv_distribution.split.
Example:
variation_meta
object
required

Configuration for A/B testing content variations.

  • SMV: Fixed percentage splits across up to 5 variations.
  • DMV: The system automatically learns which variant performs best over time and shifts traffic toward the winner.
  • Offer Control Group: A configurable percentage of eligible users to be held out as a pure control group.

Lifecycle & Mutation Rules

variation_meta can be edited later via PATCH /v5/offers/{offer_id}, subject to status-based rules. Field mutability depends on both the offering status and the variation type. Attempting to modify a locked field returns a 400 IMMUTABLE_FIELD error.

Example:
description
string

Optional free-text description of the offering's purpose, targeting rationale, or expected user experience. Visible in the MoEngage UI offering list.

Maximum string length: 500
Example:

"20% discount for returning users who have not purchased in 30 days"

tags
string[]

Tags that provide context about the Offering's nature or theme. Each tag ID must already exist in the workspace — the service returns 400 INVALID_TAG_ID for any unknown tag ID.

Maximum array length: 10
Example:
capping_rules
object

Frequency capping configuration that limits how often this offering is delivered. Two independent capping rules can be configured and enabled simultaneously.

overall: Limits the TOTAL number of times the offering is delivered across ALL users in the target segment within the capping schedule period.

user_level: Limits the number of times any SINGLE user can receive the offering within the capping schedule period.

Example:
is_global_control_enabled
boolean
default:false

Whether the global control group is enabled.

imp_track_hours
integer

The attribution window in hours.

Required range: 1 <= x <= 240
Example:

36

offering_attribute_configuration
object[]

Custom attributes assigned to this offering. These attributes are used in Decision Policy using the Custom formula ranking strategy.

Maximum array length: 5
conversion
object

Conversion goal configuration for measuring offering effectiveness. This can be set at creation time or later via PATCH while the offering is still in "scheduled" status. Once the offering goes "active", the conversion configuration is locked to preserve Thompson Sampling statistical integrity.

Response

Offering created successfully.

Response returned by POST /v5/offers on successful creation.

response_id
string

Format: resp_<X-MOE-Request-Id> header value (auto-generated UUID if the X-MOE-Request-Id header was not part of the request body).

Example:

"resp_c5f83262-3127-4e23-bc1b-9efd4c929e12"

type
enum<string>

Resource type discriminator. Always offer.

Available options:
offer
data
object

Created offering summary.