steverice

An example of a relationship is Notification Rules, whose primary meaning is as a link between a user and a contact method. No individual notification rule has a unique, name-worthy meaning, and so they are handled (read and written) only as a collection. There is no compelling reason to update a single notification rule in place rather than replace the entire object with a new one. While this might seem like a significant loss of functionality, data shows that a trivially small number of clients outside of the PagerDuty web app are using it:

• over the last 30 days, only 11 requests were made to PUT notification_rules/id using non-cookie authentication, and all by the subdomain redacted. While the mobile team experimented with it in the latest "Edit Notification Rules" update in 3.6, they've confi

steverice

module Api
  module V2
    class SchedulesController < Api::V1::SchedulesController
    end
  end
end

steverice

Hello,

Thanks for your continued interest and use of the PagerDuty API.

We're writing to let you know that as of November 4th, 2015, we will be discontinuing the ability to authenticate against the API using HTTP Basic Authentication (PagerDuty username and password), which has been deprecated since mid-2014.

We are doing this to improve security of PagerDuty accounts by limiting the spread of PagerDuty user passwords, which are difficult to audit and revoke should they become compromised.

Additionally, the need to authenticate a user via HTTP Basic Authentication imposes a performance penalty on every API request due to the robust hashing techniques we use to store and validate user passwords. This is done by design to make brute forcing passwords computationally infeasbile.

steverice

PagerDuty API v2 is Now in Beta!

PagerDuty is thrilled to announce that the new version of our popular PagerDuty REST API is now available for everyone to use in beta!

We've been working hard on this version of the API for a while and are excited about the improvements in speed, consistency, and ease of use that API v2 delivers.

If you're a PagerDuty customer, you've already been using API v2 for a while every time you use our web application. In our own experience, we've found it easier to work with and build new functionality using API v2 than ever before.

What's new?

steverice

The API Approval Process

When do I need approval for an API change?

Approval is needed before shipping any change used by one or more wild clients or releasing the API for general availability. In other words, the API must be contracted.

If you are working on a prototype API, you may ship your code at will, but you acknowledge the following tradeoffs:

• you are responsible to make any and all code changes to satisfy the final approved proposal before general availability
  • in other words, there will be additional churn
• you have communicated to any clients of the prototype API that their integration may break at any time

steverice

{
	"swagger": "2.0",
	"info": {
		"title": "PagerDuty API",
		"description": "The PagerDuty API provides programmatic access to entities within a PagerDuty account. It is designed around [RESTful principles](https://en.wikipedia.org/wiki/Representational_state_transfer) with a path structure based on resources and their relationships.\n\nAll requests and responses are serialized in [JSON](https://en.wikipedia.org/wiki/JSON), including error responses.\n\nSchema are designed to be reusable across requests and across endpoints.\n\nMore sophisticated API clients should treat PagerDuty resources as unique objects keyed by the `id` field that can be used in any API request involving resources of that type.\n\nEvery resource contains a `type` field that identifies the schema it uses.\n\n## Rate limiting\n\nEach account and authentication mechanism is limited to the number of API requests it can make every minute. API requests that exceed the API rate limit will return an [HTTP status code](error_codes.html#http_res

steverice

---
title: PagerDuty Developer
layout: main
---
<ul class="breadcrumb">
  <li>
    <a href="/documentation/rest/">REST API</a>
  </li>
  <li style="list-style: none">
    <span class="divider">/</span>

steverice

API v2 Vision 👓

This document outlines the vision and scope for v2 of the API.

Ordered lists represent prioritized order. We recannot accomplish everything at once, and thus everything needs to be prioritized sooner or later. I choose sooner.

This document does not attempt to present a comprehensive record of all the changes that will be made, as those will be captured by stories in JIRA. Instead, it establishes the goals, principles, and patterns that we'll use to make the decisions about what needs to change.

It is a living document and will evolve as we discover new edge cases and outliers that weren't previously considered.

steverice

1. Set up PR fetch aliases to make pulling PRs easy: https://gist.github.com/gnarf/5406589
2. Set up RubyMine as external diff viewer in SourceTree: http://www.jetbrains.com/ruby/webhelp/running-rubymine-as-a-diff-or-merge-command-line-tool.html and http://stackoverflow.com/questions/14774053/intellij-diff-tool-in-sourcetree (bin path for me is /Applications/RubyMine.app/Contents/MacOS/rubymine)
3. Bookmark a temp repo that you use to grab PRs in SourceTree
4. ???
5. PROFIT!

steverice

/**
 * Example: incoming property name (e.g. from PHP) has square brackets, e.g. names[0][1]
 * var property = names[0][1];
 * var value = {
 * 	names: [
 * 		['some', 'data', 'here']
 * 	]
 * }
 * result: value == 'some'
 *