Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintfax.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
Status, changelog, and postmortems

mintfax publishes service health, API changes, and incident reports through three channels: a real-time status page, a versioned changelog, and structured postmortems. Each channel covers a different time horizon. The status page is live. The changelog is per-release. Postmortems come after resolved incidents. If you are integrating for the first time, the quickstart is a better starting point. This page is for teams already running mintfax in production.

​
Sub-pages

ChannelWhat it coversWhere it lives
Status pageReal-time health for the API, carrier network, and dashboardExternal status service (see below)
ChangelogPer-version API changes with breaking-change calloutsThis page (below)
PostmortemsStructured incident reports with timeline, root cause, and customer impactThis page (below)

​
Status page

The mintfax status page reports health across three categories. API health. Covers the API Gateway, Lambda Authorizer, Ingest Lambda, and SQS queue. A degraded state here means fax submissions may fail or queue slower than expected. Carrier health by region. Shows per-region delivery success rates and latency for each active carrier. A carrier issue in one region does not necessarily affect others. When multiple carriers serve a destination, mintfax routes around single-carrier failures. Dashboard health. Covers the Laravel application layer: control panel, billing, webhook management, and account settings. Dashboard outages do not affect faxes already in the queue. The external status service URL will be published here once the provider is selected. Subscribe to updates via email or RSS from that page.

​
Subscribing to status changes

No polling required. Subscribe through the external status service to get notified of:
  • Component state changes (operational, degraded, partial outage, full outage)
  • Scheduled maintenance windows
  • Incident updates and resolution confirmations
When service health events are available, mintfax will also deliver them to your webhook endpoints. These notifications are best-effort during an outage, since the webhook delivery system itself may be affected.

​
Changelog

The changelog records every API change that could affect your integration. Entries carry a release date and version identifier.

​
What gets a changelog entry

  • New endpoints or request parameters
  • Changed response shapes or field types
  • Deprecated fields or endpoints, with a removal timeline
  • Breaking changes, always called out with a warning block
  • New event types for webhook subscriptions
  • Changes to rate limits, retry behavior, or default values
  • Sandbox behavior changes

​
Changelog entry format

## v1.x.x - YYYY-MM-DD

Summary of what changed and why.

### Breaking changes

Description of the breaking change, what it replaces, and the migration path.

### New

- Description of new feature or endpoint

### Changed

- Description of changed behavior

### Deprecated

- Description of deprecated item and removal timeline

### Fixed

- Description of bug fix
Breaking changes always appear first. Releases without breaking changes omit that section.

​
Reading the changelog programmatically

The changelog is available as structured data at the /changelog endpoint of the mintfax docs site. You can also watch the mintfax-core repository for tagged releases. Release notes include the full changelog entry.

​
Postmortems

When an incident affects customer-facing services, mintfax publishes a postmortem within five business days of resolution. An incident qualifies for a postmortem if it meets at least one of these criteria:
  • API availability dropped below normal operating levels for more than five minutes
  • Fax delivery was delayed or failed for a measurable number of customers
  • A data integrity issue affected fax records, balances, or webhook delivery
  • A security event required customer notification

​
Postmortem format

Every postmortem follows a fixed structure:
SectionWhat it contains
Incident summaryOne-paragraph description of what happened and how long it lasted
TimelineTimestamped sequence from detection through response, mitigation, and resolution
Root causeTechnical explanation of why the incident occurred
Customer impactWhich services were affected, how many customers saw impact, and what they experienced
Action itemsSpecific changes to prevent recurrence, each with an owner and target date
Postmortems name the root cause directly. No vague language like “a system issue.” If a carrier failed, the postmortem says which carrier and what broke. If a deployment introduced a bug, it identifies the change.

​
Accessing past postmortems

Postmortems are published as individual entries linked from the external status service and indexed on this page. Once the first postmortem ships, a chronological index will appear here.

​
Quick-start

  1. Subscribe to the status page. When the external status service goes live, subscribe to the components relevant to your integration: API, the carrier regions you send to, and the dashboard if you depend on it.
  2. Check the changelog before upgrading. Before updating your integration code, read the latest changelog entries. Look for breaking changes first.
  3. Register a webhook for service events. When service health events ship, add them to your webhook subscription for programmatic health notifications.
mintfax does not publish uptime guarantees or SLA percentages on this page. The status page shows current and historical state. For a formal availability commitment, contact support.