Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
We've been showing our public API some love this week, with new endpoints, and some custom field improvements.
If you've not seen it before, our API documentation contains everything you need to get up and running.
As features, actions and follow-ups used to look pretty similar to each other — but over time, they've changed. Our public API hadn't quite evolved with them: our Actions V1 API endpoints return both follow-ups and actions.
That became pretty confusing, so we've split them. We now have Actions V2 and Follow-ups V2 endpoints available via our public API. This makes it easier to differentiate the two, and also means that we can return more information about follow-ups. We now provide the follow-up priority, external issue reference, and description.
We hope that this split will make life easier for anyone who wants to build their own follow-ups integrations: whether that's custom reporting, or integrating with issue trackers that we don't support yet. Check out Actions V2 and Follow-ups V2 in our API documentation for the full details.
You can now list users using our public API. This is particularly helpful when using other API endpoints that take a user ID, such as when you're assigning an incident role to somebody. The list users endpoint will also let you know the role of each user, as well as their name, email and Slack user ID.
When we released Catalog, we also included the ability to have custom fields powered by catalog types. We now have support for this within the API, allowing you to see (and set) the values for these fields just as you would with any others.
You can see this in action in the incidents API, where custom field values now include the catalog entry.
We’ve been quite busy here shipping a lot of smaller features, bits of polish and bug fixes. See below for all the items the team has been up to: