Home / Basics / Highnote API
API Status and Changes
Highnote provides transparency on the operational status of the platform and GraphQL using the Highnote Status Page. You can subscribe to updates on the page and will be notified of any downtime.
When an incident impacts the platform and GraphQL API, the Highnote team immediately begins investigating, assessing the impact, and communicating via the status page.
Refer to the following details of each phase and the activities that occur in each phase:
| Phase | Activities |
|---|---|
| Incident identification | When an incident has been identified, Highnote will create an incident in the incident tracking system and begin the investigation. |
| Investigation and communication | The Highnote Incident Commander and incident response team work to investigate the issue, determine the scope, and identify a resolution. Based on the scope and severity, the Highnote status page is updated with partial or full outages. |
| Resolution and communication | Once the resolution is identified and tested, the fix is deployed to production. The Highnote team will then communicate update(s) to you through the Highnote status page. |
| Post mortem | After the incident management process has occurred, the Highnote incident response team walks through what happened, the resolution, and lessons learned for future improvements. |
To maintain uninterrupted service, we recommend building robust and resilient integrations that can adapt to API and platform changes.
When changes occur on the Highnote platform and GraphQL API, the Highnote team reviews them to assess their impact and communicates with you proactiveally about the upcoming changes. The following table provides details of each phase for implementing platform changes and the activities that occur in each phase.
| Phase | Activities |
|---|---|
| Planning | Once a change is determined, change planning begins. This includes documenting the change and its impact. |
| Communication and documentation | The Highnote team ensures that the change's documentation is completed and that your usage is reviewed to determine its impact on you. Highnote creates communication that includes the change's description, the reason for the change, the potential impact on you of the change, and the timing. For more information on communication timelines, see Additive Changes and Breaking Changes. |
| Implementation | Highnote ensures the execution of communication to you by Highnote Customer Support. This includes performing the change as documented. |
| Retrospective | After the change is launched, Highnote holds a retrospective to reflect on the change management process. |
Additive changes refer to modifications of notifications or Highnote's API schema that introduce new features, functionality, or resources without altering or removing existing components.
All additive changes are recorded in the API and product changelogs. Direct communications for additive changes are only sent when an additive change results in a business or user experience change. For more information on additive changes, see the Changelog page.
Breaking changes refer to modifications to notifications and/or Highnote’s API schema that alters existing behavior in a way that may cause existing client applications and integrations to break or malfunction.
Highnote provides 90 days notice before releasing breaking changes.