💡 Feature Requests

The subscription management API endpoints is lacking one very important feature, namely being able to assign the subscription to a subscription group. Without support for subscription group assignment the whole concept of subscription groups is useless for anyone managing subscriptions programmatically. Use case: syncing subscriptions from a CRM system to StatusPal, with different audiences (subscription groups) that should be selectable in StatusPal when sending notifications. Scope limitation: managing the actual subscription groups via API is not necessary for our use case, simply being able to add/remove subscription membership to an existing subscription group is fine.

When automating status page provisioning via the StatusPal API or Terraform provider, there's no way to programmatically retrieve the member invite link for a status page. Current Behavior: - The invite link (https://{subdomain}. statuspal.io/registrations/new?sp_access={token} ) contains an sp_access token that is only visible in the StatusPal web UI - The API endpoints (GET /api/v2/status_pages/{subdomain}) do not return this token - The Terraform provider (statuspal_status_page resource) does not expose this value Requested Feature: Add the sp_access token or full invite URL to the API response when fetching status page details, so it can be: 1. Retrieved via the REST API (GET /api/v2/status_pages/{subdomain}) 2. Exposed as an attribute in the Terraform provider (statuspal_status_page.invite_link or statuspal_status_page.sp_access_token) Use Case: We're automating status page creation for multiple tenants using Terraform. After creating each status page, we need to share the invite link with tenant administrators so they can register and manage incidents. Currently, this requires manual lookup in the UI for each status page, breaking our automation workflow. Suggested API Response Addition: { "status_page": { "subdomain": "example", "name": "Example Status", "invite_url": " https://example.statuspal.io/registrations/new?sp_access=abc123 ", "sp_access_token": "abc123", ... } }

The services {{incident.services}} are currently under a {{incident.type}} incident.

Allow to see history information showcasing who performed changes on the status pages and their resources.

It will be great to allow updating several status pages on an incident or maintenance without going and updating one by one

Introduce built-in PostHog analytics integration for StatusPal status pages, including page views, unique visitors, and usage trends.

Dear StatusPal Support Team, We understand that StatusPal currently provides only a single type of API key, which requires full access even for read-only use cases. From a security and least-privilege perspective, we would like to request support for read-only API keys (GET access only). For external dashboards and status visualization, read-only access is sufficient, and using full-access keys introduces unnecessary risk. Providing read-only API keys would enable safer API usage and encourage broader adoption of StatusPal integrations. Thank you for your consideration. Best regards,

We have a service that has been decommissioned and we would like to archive it and all belonging logged events.

It would be extremely handy for a button , backup and another restore if we could export past incidents from one subscription and import them to another. We are in a middle of a company split and we need that so we dont loose historical data

Allow service dependency configuration be deployed over TF and API