Create Offering
Create a new Offering in the workspace.
Rate Limit
The rate limit is 100 requests per minute, 300 requests per hour, and 600 requests per day per consumer.Authorizations
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
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.
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
Request body for creating an Offering via POST /v5/offers.
Required fields: name, priority, delivery, created_by, scheduling,
segment_info, offer_content, variation_meta.
Unique display name for this offering within the workspace. Names are case-sensitive and must be unique. Allowed characters: alphanumeric characters and underscores (_).
5 - 100"Summer_Sale_Promo_2026"
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.
1 <= x <= 100Controls when the offering is eligible for delivery. scheduled — the offering is served within its scheduling window.
scheduled Email address of the user creating this offering.
"marketing-team@example.com"
Scheduling window that determines when an offering is eligible for delivery.
Both start_datetime and expiry_datetime are required when creating an offering.
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": {} }
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_1object 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
localesmap 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
variationsmap keys must exactly match the variation IDs defined invariation_meta.variantsPerLocaleandsmv_distribution.split.
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.
Optional free-text description of the offering's purpose, targeting rationale, or expected user experience. Visible in the MoEngage UI offering list.
500"20% discount for returning users who have not purchased in 30 days"
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.
10Frequency 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.
Whether the global control group is enabled.
The attribution window in hours.
1 <= x <= 24036
Custom attributes assigned to this offering. These attributes are used in Decision Policy using the Custom formula ranking strategy.
5Conversion 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.
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).
"resp_c5f83262-3127-4e23-bc1b-9efd4c929e12"
Resource type discriminator. Always offer.
offer Created offering summary.