Endpoints
The Content APIs are a collection of the following endpoints:- List Content APIs: Returns all content APIs in the workspace, or a single one specified by name or ID.
- Test Content API: Calls the upstream endpoint of a saved content API and returns the response.
Authentication
Authentication is done via Basic Auth. This requires a Base64-encoded string of your credentials in the formatusername:password.
- Username: Use your MoEngage Workspace ID (also known as the App ID). Find it in the MoEngage dashboard at Settings > Account > API keys.
- Password: Use an API key from Settings > Account > API keys.
Personalization Tokens
A content API configuration can include Jinja tokens in its URL, parameters, headers, or body. Tokens are grouped by namespace — for example,{{UserAttribute['city']}} or {{EventAttribute['name']}}.
When you test a configuration, supply sample values for these tokens in the dynamic_values object of the request body, keyed by namespace. A token like {{UserAttribute['city']}} resolves from dynamic_values.UserAttribute.city. MoEngage resolves every token before calling the upstream endpoint.
Omit the request body if the configuration has no tokens.
Pagination
List Content APIs returns at most 20 items per page. Treat the cursor as opaque — do not decode or modify it. To page through every content API in the workspace:-
Request the first page with
limitalone.First Page -
Check
pagination.has_morein the response. When it istrue, send the same request again withpagination.next_cursorpassed back as thecursorparameter, keepinglimitunchanged.Next Page -
Repeat step 2 until
pagination.has_moreisfalse.
FAQs
Manage Content APIs
Can I create or edit a content API with these endpoints?
Can I create or edit a content API with these endpoints?
No. These endpoints are read-only, apart from the test call. Create and edit content APIs from the MoEngage dashboard. For more information, see Add a Content API.
How do I fetch a single content API?
How do I fetch a single content API?
Pass either
name or id to List Content APIs. Supplying both returns a 400 error. Omit both to list every content API in the workspace.Why is the request_body field empty for my content API?
Why is the request_body field empty for my content API?
A request body applies only to
POST and PUT content APIs. For GET configurations, request_body is empty and request_body_type does not affect the call.What does the verified field mean?
What does the verified field mean?
verified becomes true once the content API has returned a successful test response. last_tested_at records when that test ran.Test Content APIs
Do I always need to send a request body when testing?
Do I always need to send a request body when testing?
No. The request body is optional. Send it only when the saved configuration contains Jinja tokens that need sample values. Omit it entirely otherwise.
The test returned 200, but the data looks wrong. What should I check?
The test returned 200, but the data looks wrong. What should I check?
A
200 means MoEngage reached the upstream endpoint — it does not mean the upstream call succeeded. Check data.api_response_code for the status code the upstream endpoint returned, and data.api_response_body for its response.Why did my test return a 400 error?
Why did my test return a 400 error?
Either the request body failed validation, or the saved configuration’s URL resolves to an internal or private IP range. MoEngage validates the URL against server-side request forgery (SSRF) and rejects those addresses.
How do I stop sensitive fields from appearing in responses?
How do I stop sensitive fields from appearing in responses?
List them in the content API’s
pii_fields_in_response configuration. Fields marked this way are treated as personally identifiable information (PII).