ShipPulse
  • Pricing
  • Docs
  • Blog
  • Compare

Product

TestimonialsChangelogStatus PagesFeedbackRoadmapPricing

Resources

DocsBlogAPI ReferenceSDKHelp Center

Company

AboutContact

Legal

TermsPrivacyCookie PolicyDPASub-processors

Product updates

Changelog updates only. Unsubscribe any time.

ShipPulse operated by Igor Bogdanov, Limassol, Cyprus. [email protected]. Cyprus registration number pending — will be published once issued.

ShipPulse

© 2026 ShipPulse. All rights reserved.

OverviewQuick StartCore ConceptsWidget ReferencePlatform GuidesAPI ReferenceAPI PlaygroundError HandlingPaginationRate LimitingJavaScript SDKWebhooksZapier, n8n & MakeCustom DomainsTeam ManagementBilling & PlansNotification ChannelsAI FeaturesOverviewFrom SenjaFrom Testimonial.toFrom HeadwayFrom Canny

Introduction

  • Overview
  • Quick Start
  • Core Concepts

Embed Widgets

  • Widget Reference
  • Platform Guides

REST API

  • API Reference
  • API Playground
  • Error Handling
  • Pagination
  • Rate Limiting

SDK & Webhooks

  • JavaScript SDK
  • Webhooks
  • Zapier, n8n & Make

Guides

  • Custom Domains
  • Team Management
  • Billing & Plans
  • Notification Channels
  • AI Features

Migrations

  • Overview
  • From Senja
  • From Testimonial.to
  • From Headway
  • From Canny

Need help?

[email protected]
Introduction

Core Concepts

The ShipPulse data model in plain English. Understanding these building blocks will help you navigate the dashboard, use the API, and set up widgets correctly.

Architecture overview

Everything in ShipPulse is organized around Projects. A project contains modules, and each module powers one or more public pages and embeddable widgets.

Organization (your account)
└── Project (e.g. "MyApp")
    ├── API Key (sp_...)
    ├── Team members
    │
    ├── Module: Testimonials
    │   ├── Testimonials (approved, pending, rejected)
    │   ├── Widgets (Wall of Love, Carousel, Popup, ...)
    │   └── Public page → /wall/my-app
    │
    ├── Module: Changelog
    │   ├── Entries (published, draft)
    │   ├── Subscribers (email subscribers)
    │   ├── Widget (embeddable changelog strip)
    │   └── Public page → /changelog/my-app
    │
    ├── Module: Status Page
    │   ├── Monitors (HTTP, TCP, Cron)
    │   ├── Incidents (open, resolved)
    │   └── Public page → /status/my-app
    │
    ├── Module: Feedback Board
    │   ├── Feedback requests (voted, pending)
    │   ├── Comments
    │   └── Public page → /feedback/my-app
    │
    └── Module: Roadmap
        ├── Roadmap items (Planned, In Progress, Done)
        ├── Subscriptions (per-item email alerts)
        └── Public page → /roadmap/my-app

Entity glossary

Project

The top-level container. A Project maps to one product or brand. It has its own API key, team members, and modules. All public pages (changelog, status, wall) are scoped to a project.

Example: "MyApp", "Marketing Site", "Client Acme"

Module

A feature set within a project. Each project can enable up to 5 modules: Testimonials, Changelog, Status Page, Feedback Board, and Roadmap. Modules share the same project identity but are independent.

A project can have Testimonials + Changelog enabled but not Status Page.

Widget

An embeddable JavaScript snippet that renders module content on any external site. Widgets use Shadow DOM so they never conflict with host-page CSS. Each widget has its own config (type, theme, filters).

Wall of Love widget, Changelog widget, Status badge widget.

Monitor

An uptime check belonging to the Status Page module. A monitor checks a URL (HTTP), TCP port, or cron job on a configurable interval. Results are stored and used to compute status (operational, degraded, down).

{ url: "https://api.myapp.com/health", interval: 60, type: "http" }

Incident

A declared outage or degradation on a Status Page. Incidents have a severity level (minor, major, critical) and can have multiple update entries as the situation evolves. Resolved incidents stay visible in the incident history.

impact: "major" | "minor" | "critical"

Feedback Board

A public page where users submit feature requests and bug reports. Each submission can be upvoted, commented on, and linked to a Roadmap item. The board can be moderated — submissions require approval before going public.

shippulse.dev/feedback/my-project

Roadmap Item

A card on the public Roadmap with a title, description, and Kanban status (Planned, In Progress, Done). Roadmap items can be linked to Feedback requests. Subscribers are notified when status changes.

status: "planned" | "in_progress" | "done"

Subscriber

A user who has opted in to receive email notifications from a project. Subscribers are collected from changelog email notifications, status page alerts, and roadmap item subscriptions. All subscriptions are double-opt-in.

A subscriber to your changelog gets an email every time you publish a new entry.

API Key

A secret token scoped to a single project, used to authenticate REST API requests. API keys begin with sp_ and can be rotated in project Settings → API Keys. Available on Pro and Agency plans.

Authorization: Bearer sp_live_abc123...

On-call Schedule

A rotation schedule that determines who receives incident alerts at any given time. Defined per project with daily/weekly rotations. Alerts are sent via email, Slack, or webhook.

Week 1: Alice. Week 2: Bob. Fallback: [email protected]

How entities relate

Project → Modules: A project can have multiple modules enabled. Each module is independent — you can enable just Testimonials and Changelog, and add Status Page later.

Feedback → Roadmap: Feedback requests can be linked to Roadmap items. When you ship a roadmap item, linked feedback requests are automatically marked as shipped and subscribers notified.

Roadmap → Changelog: When marking a roadmap item as Done, you can optionally link it to a Changelog entry. This gives subscribers the full release context.

Monitor → Incident: Monitors detect downtime and can auto-create incidents (if enabled). You can also create incidents manually via the dashboard or API before monitoring picks up an issue.

Subscriber: A subscriber is scoped to a specific module within a project. A user can be subscribed to your changelog but not your status page — subscriptions are independent.