API Status and Changes
API and platform status
Highnote provides transparency on the operational status of the platform and GraphQL API 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. |
API changes
When changes occur to the Highnote GraphQL API, the Highnote team reviews them to assess their impact and communicates with you proactively about the upcoming changes. The following table provides details of each phase for implementing API 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
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 changelog. Direct communications for additive changes are only sent when an additive change results in a business or user experience change.
Breaking changes
Breaking changes refer to modifications to notifications and/or Highnote's API schema that alter 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.
Monitoring changes
SchemaChangelog covers GraphQL schema changes only — Dashboard and UI changes are not included.To retrieve API schema changes programmatically, use the schemaChangelogs query. Each request returns a paginated list of recent schema changelogs; re-query on your own cadence to detect new entries.
Each SchemaChangelog node corresponds to a specific deploy and groups changes under their schema root paths.
Every change includes a changeType (for example, FIELD_ADDED), a human-readable message, and a criticality level of BREAKING, DANGEROUS, or NON_BREAKING.
Use pageInfo.endCursor with the after argument to page forward while pageInfo.hasNextPage is true.
SchemaChangelogs
Query
query SchemaChangelogs($first: Int! = 10, $after: String) {
schemaChangelogs(first: $first, after: $after) {
edges {
node {
id
createdAt
changes {
rootPath
changes {
path
changeType
message
criticality {
level
}
}
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Variables
{ "first": 10, "after": null }
Result
{
"data": {
"schemaChangelogs": {
"edges": [
{
"node": {
"id": "<SCHEMA_CHANGELOG_ID_1>",
"createdAt": "2026-04-24T00:41:33.367Z",
"changes": [
{
"rootPath": "Mutation",
"changes": [
{
"path": "Mutation.simulateFlexibleCredentialAuthorization",
"changeType": "FIELD_ADDED",
"message": "Field 'simulateFlexibleCredentialAuthorization' was added to object type 'Mutation'",
"criticality": {
"level": "NON_BREAKING"
}
}
]
},
{
"rootPath": "SimulateFlexibleCredentialAuthorizationInput",
"changes": [
{
"path": "SimulateFlexibleCredentialAuthorizationInput",
"changeType": "TYPE_ADDED",
"message": "Type 'SimulateFlexibleCredentialAuthorizationInput' was added",
"criticality": {
"level": "NON_BREAKING"
}
}
]
}
]
}
},
{
"node": {
"id": "<SCHEMA_CHANGELOG_ID_2>",
"createdAt": "2026-04-22T02:20:02.185Z",
"changes": [
{
"rootPath": "AccountHolder",
"changes": [
{
"path": "AccountHolder",
"changeType": "UNION_MEMBER_ADDED",
"message": "Member 'Business' was added to Union type 'AccountHolder'",
"criticality": {
"level": "DANGEROUS"
}
}
]
}
]
}
},
{
"node": {
"id": "<SCHEMA_CHANGELOG_ID_3>",
"createdAt": "2026-04-17T21:18:59.056Z",
"changes": [
{
"rootPath": "PaymentTransactionResponseCodeProcessorResponseCode",
"changes": [
{
"path": "PaymentTransactionResponseCodeProcessorResponseCode.AUTHENTICATION_REQUIRED",
"changeType": "ENUM_VALUE_ADDED",
"message": "Enum value 'AUTHENTICATION_REQUIRED' was added to enum 'PaymentTransactionResponseCodeProcessorResponseCode'",
"criticality": {
"level": "DANGEROUS"
}
}
]
}
]
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "<END_CURSOR>"
}
}
}
}