Announcement Management API

The AnnouncementManagement API lets you create, manage, and publish banners, newsfeeds, and popups programmatically. Use it when you want to automate announcements from your own systems — for example, triggering a banner from a deployment pipeline, or publishing a newsfeed post when a feature ships — without going through the Product Fruits dashboard.

Authentication

All endpoints require Bearer authentication via the Authorization header:

Authorization: Bearer <api-key>

The API spec does not define a base URL. Use your standard Product Fruits public API host.

The API is split into three independent resource groups. There is no unified /announcements endpoint — each type is managed separately:

• banners — /v1/banners
• newsfeeds — /v1/newsfeeds
• popups — /v1/popups

Supported Endpoints

All three resource types expose the same operations.

announcementId is a UUID — a unique identifier automatically assigned to an announcement when it is created. You will need it for all endpoints that operate on a specific announcement: get, update, delete, publish, and unpublish.

Banners

GET    /v1/banners                              List
GET    /v1/banners/{announcementId}             Get by ID
POST   /v1/banners                              Create
PUT    /v1/banners/{announcementId}             Update
DELETE /v1/banners/{announcementId}             Delete
PUT    /v1/banners/{announcementId}/publish     Publish
DELETE /v1/banners/{announcementId}/publish     Unpublish

Newsfeeds

GET    /v1/newsfeeds                            List
GET    /v1/newsfeeds/{announcementId}           Get by ID
POST   /v1/newsfeeds                            Create
PUT    /v1/newsfeeds/{announcementId}           Update
DELETE /v1/newsfeeds/{announcementId}           Delete
PUT    /v1/newsfeeds/{announcementId}/publish   Publish
DELETE /v1/newsfeeds/{announcementId}/publish   Unpublish

Popups

GET    /v1/popups                               List
GET    /v1/popups/{announcementId}              Get by ID
POST   /v1/popups                               Create
PUT    /v1/popups/{announcementId}              Update
DELETE /v1/popups/{announcementId}              Delete
PUT    /v1/popups/{announcementId}/publish      Publish
DELETE /v1/popups/{announcementId}/publish      Unpublish

The list endpoint returns results in pages rather than all at once. Use the page and pageSize query parameters to control which page you want and how many results to return per request:

GET /v1/{type}?page=1&pageSize=20

page is the page number (starting at 1) and pageSize is the number of results per page.

Request Model

POST (create) and PUT (update) share the same request body structure across all three types.

Content Object

The content field is a locale-keyed map, where each key is a locale (e.g. "en", "fr") and the value is a per-locale content object. The locale-keyed structure is inferred from additionalProperties in the schema — there is no fixed top-level key.

There is no status field in the request body, publish state is controlled through dedicated /publish endpoints.

The available sub-fields inside each locale object depend on the announcement type:

Note: there is no unified top-level title field. The title sub-field only exists inside the per-locale content object, and only for newsfeeds and popups.

Banner Example: title is not supported:

{
  "name": "Maintenance window",
  "format": "markdown",
  "content": {
    "en": {
      "content": "Scheduled maintenance on Sunday 01:00–03:00 UTC.",
      "ctaText": "See status page"
    }
  },
  "cta": {
    "url": "https://status.yourapp.com"
  }
}

Newsfeed or Popup Example: title is supported:

{
  "name": "October release",
  "format": "markdown",
  "content": {
    "en": {
      "title": "Here's what's new",
      "content": "Your markdown content here.",
      "ctaText": "Read the changelog"
    }
  },
  "cta": {
    "url": "https://yourapp.com/changelog"
  },
  "segment": 1042
}

Response Codes

Success codes

Error codes

Known Limitations (Subject to Change)

The following aspects are not yet fully defined in the API specification and may change in future updates:

• Success response body schemas for list, get, create, update, publish, and unpublish operations are not documented
• The only supported value for format is markdown; no other allowed values are currently defined
• HTTP status codes 403, 409, 422, and 429 are not documented
• The requestId field in responses is not documented
• Publish/unpublish idempotency behavior is not defined (e.g., publishing an already published announcement or unpublishing an already unpublished one)
• It is not specified whether an announcement must be unpublished before it can be deleted
• Role- and plan-based access restrictions are not documented at the endpoint level