Summary and recommendation
The Meltwater public API is scoped exclusively to media intelligence data - searches, editorial content, and social analytics. It does not expose any user-management endpoints. Authentication uses a proprietary key pair (x-user-email + x-user-key request headers), not OAuth 2.0, which limits composability with identity graph tooling that expects standard bearer token flows.
Rate limits are enforced per API key but tier-specific numbers are not published in official developer documentation. Pagination uses a cursor-based model with a `next` parameter; default and maximum page sizes are not publicly documented. No webhooks or event-notification system for user lifecycle events exists in official Meltwater resources.
API quick reference
| Has user API | No |
| Auth method | API Key (x-user-email + x-user-key request headers) |
| Base URL | Official docs |
| SCIM available | No |
| SCIM plan required | Custom |
Authentication
Auth method: API Key (x-user-email + x-user-key request headers)
Setup steps
- Log in to Meltwater as an account admin.
- Navigate to Settings > API Access to generate an API key.
- Include the key in every request as the x-user-key header and your account email as x-user-email.
User object / data model
User object field mapping is not yet verified for this app.
Core endpoints
Endpoint coverage is not yet verified for this app.
Rate limits, pagination, and events
- Rate limits: Rate limits are enforced per API key. The public developer docs reference a default limit but do not publish tier-specific numbers.
- Rate-limit headers: Unknown
- Retry-After header: Unknown
- Rate-limit notes: Official docs advise contacting Meltwater support for rate limit details specific to your contract.
- Pagination method: cursor
- Default page size: 0
- Max page size: 0
- Pagination pointer: next
| Plan | Limit | Concurrent |
|---|---|---|
| Standard API access | Not publicly documented | 0 |
- Webhooks available: No
- Webhook notes: No webhook or event-notification system for user lifecycle events is documented in official Meltwater developer or help center resources.
- Alternative event strategy: Meltwater supports SAML 2.0 SSO (Okta, Entra ID, OneLogin) for authentication federation. User provisioning and deprovisioning must be performed manually through the Meltwater admin UI.
SCIM API status
- SCIM available: No
- SCIM version: Not documented
- Plan required: Custom
- Endpoint: Not documented
Limitations:
- No SCIM provisioning is documented in official Meltwater help center or developer portal as of the policy date.
- User lifecycle management (invite, deactivate, role assignment) is performed via the Meltwater admin UI only.
- SSO via SAML 2.0 is supported but does not include automated provisioning/deprovisioning.
Common scenarios
Onboarding a new user has no API path. The full flow - navigate to Settings > Users > Invite User, assign a role, and await email activation - is UI-only. If SSO is configured, the user authenticates via the IdP on first login, but the Meltwater account itself must still be created manually beforehand.
Deprovisioning is equally constrained. Revoking an IdP session does not automatically remove or deactivate the Meltwater account; an admin must separately locate the user in Settings > Users and execute the deactivate or remove action. SSO enablement itself is not self-serve - it requires opening a support request with Meltwater, providing IdP metadata, and coordinating configuration on both sides. SCIM provisioning is not bundled with SSO setup and is not documented as available under any contract tier.
Onboard a new user
- Admin logs into Meltwater.
- Navigates to Settings > Users > Invite User.
- Enters the user's email and assigns a role.
- User receives an email invitation to activate their account.
- If SSO is configured, user authenticates via the IdP on first login.
Watch out for: There is no API endpoint to automate this flow; it must be completed in the UI.
Deprovision a departing user
- Admin navigates to Settings > Users in Meltwater.
- Locates the user and selects Deactivate or Remove.
- If SSO is in use, revoking the IdP session does not automatically remove the Meltwater account - the admin must also deactivate in Meltwater.
Watch out for: No SCIM or API-driven deprovisioning; manual step in Meltwater UI is always required.
Enable SSO for the organization
- Admin contacts Meltwater support to enable SSO on the account.
- Configures a SAML 2.0 application in the IdP (Okta, Entra ID, or OneLogin) using metadata provided by Meltwater.
- Provides the IdP metadata URL or XML to Meltwater support for configuration.
- Tests SSO login with a pilot user before rolling out broadly.
Watch out for: SSO enablement is handled by Meltwater support, not self-serve. SCIM provisioning is not bundled with SSO setup.
Why building this yourself is a trap
The core integration trap is the gap between SSO and provisioning. SAML 2.0 SSO is supported (Okta, Entra ID, OneLogin), which creates the appearance of IdP-managed access. In practice, SSO handles authentication only - group-to-role mapping and automated deprovisioning are not supported via the IdP connector.
An identity graph that models Meltwater as a fully IdP-governed app will produce incorrect access state: users whose IdP accounts are disabled or deleted remain active in Meltwater until an admin manually removes them.
There is no SCIM endpoint, no user-management REST API, and no webhook surface for lifecycle events. Any integration layer - whether a Stitchflow MCP server with 60+ deep IT/identity integrations or a custom middleware pipeline - must treat Meltwater as a manual-only node.
Automated reconciliation against the identity graph requires out-of-band admin action to close the loop.
Automate Meltwater workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
