Docs: Partner: First pass at documenting endpoints#8865
Conversation
e8b4149 to
52403ea
Compare
| #### Response Parameters | ||
|
|
||
| - __success__: (bool) Was the operation successful?. | ||
| - __error_code__: (string) Error code, if any'. |
There was a problem hiding this comment.
Looks like this quote is not intended. There's one in the next line too.
|
Thanks! I've pushed a commit to remove those quotations. |
gravityrail
left a comment
There was a problem hiding this comment.
Looking good! Just a couple of minor stylistic changes.
|
|
||
| When you become a Jetpack partner, we will provide you with your partner ID and a secret key. Typically you just pass these values directly in to the `bin/partner-provision.sh` and `bin/partner_cancel.sh` scripts. But, when calling the WordPress.com API directly, you'll first need to get an access token with for your partner ID with a scope of `jetpack-partner`. | ||
|
|
||
| To do that, you'll make a `POST` request to the `https://public-api.wordpress.com/oauth2/token` endpoint passing with the request parameters mentioned below. |
There was a problem hiding this comment.
It's probably worth linking to https://developer.wordpress.com/docs/oauth2/ here for more information.
| --url https://public-api.wordpress.com/oauth2/token \ | ||
| --header 'cache-control: no-cache' \ | ||
| --header 'content-type: multipart/form-data;' \ | ||
| --form client_id={PARTNER_ID} \ |
There was a problem hiding this comment.
Is this intended to be shell-interpolated? If so, it should probably be written as ${PARTNER_ID} or $PARTNER_ID
There was a problem hiding this comment.
Nope. I just meant it as a placeholder so the partner placed their ID there.
| 'content-type': 'multipart/form-data;' | ||
| }, | ||
| formData: { | ||
| client_id: {PARTNER_ID}, |
There was a problem hiding this comment.
This is also not valid JSON (it should be obvious to most people, but still could be a cause of confusion), so maybe declare these as a const above with dummy values and reference them as real variables.
| client_id: {PARTNER_ID}, | ||
| client_secret: {PARTNER_SECRET}, | ||
| grant_type: 'client_credentials', | ||
| scope: 'jetpack-partner' |
|
|
||
| ### Cancelling a plan | ||
|
|
||
| Cancelling a Jetpack for a given Jetpack site, as long as the partner making the cancellation request is also the partner that provisioned that plan, is fairly straightforward. To move forward, you'll need your partner secret as well as the URL of the site that you'd like to cancel the plan for. |
There was a problem hiding this comment.
Cancelling a Jetpack plan
There was a problem hiding this comment.
This is also awkward wording in general, a bit longer than it needs to be. Maybe something like:
Plans can be cancelled by making a request using your Partner Token and the URL of the site being cancelled.
| - __Method__: POST | ||
| - __URL__: https://public-api.wordpress.com/rest/v1.3/jpphp/{$site}/partner-cancel | ||
|
|
||
| `$site` is the site's domain and path where `/` in the path is replaced with `::`. For example: |
There was a problem hiding this comment.
Maybe include an example with two slashes as well, like
example.com/demo/wp becomes example.com::demo::wp
|
|
||
| ```shell | ||
| curl --request POST \ | ||
| --url https://public-api.wordpress.com/rest/v1.3/jpphp/{SITE_DOMAIN}/partner-cancel \ |
There was a problem hiding this comment.
Interpolation tweaks as per comment above
|
|
||
| var options = { | ||
| method: 'POST', | ||
| url: 'https://public-api.wordpress.com/rest/v1.3/jpphp/{SITE_DOMAIN}/partner-cancel', |
There was a problem hiding this comment.
Interpolation tweaks as per comment above
gravityrail
left a comment
There was a problem hiding this comment.
Great! Thanks for the changes. 👍
* update changelog.txt * Update readme.txt with scaffolding for 5.9 changelog and release draft shortlink * Add changelog entry for #8243 * Add changelog entry for #8296 * Add changelog entry for #8367 * Add changelog entry for #8686 * Add changelog entry for #8707 * Add changelog entry for #8709 and #8714 * Add changelog entry for #8729 * Add changelog entry for #8777 * Add changelog entry for #8780 * Add changelog entry for #8786 * Add changelog entry for #8787 * Add changelog entry for #8801 #8805 #8832 #8865 and #8804 * Add changelog entry for #8817 * Add changelog entry for #8822 * Add changelog entry for #8823 * Add changelog entry for #8829 * Add changelog entry for #8834 * move some items to major enhancements * Add changelog entry for #8836 * Add changelog entry for #8839 * Add changelog entry for #8861 * Add changelog entry for #8862 * Add changelog entry for #8863 * Add changelog entry for #8866 * Add changelog entry for #8870 * Add changelog entry for #8874 * Add changelog entry for #8875 * Add changelog entry for #8881 * Add changelog entry for #8890 * Add changelog entry for #8911 * Add changelog entry for #8927 * Add changelog entry for #8931 * Add changelog entry for #8933 * Add changelog entry for #8930 * fix wording * typo * minor fixes * replace partner scripts for Jetpack Start in changelog entry * Update to-test.md * Update to-test.md * minor style fixes to to-test.md * minor style fixes to to-test.md * minor fixes on to-test.md * Add changelog entry for #8868 * Add changelog entry for #8844 * Add changelog entry for #8664 * Add changelog entry for #8935 * Add changelog entry for #8425 * Add changelog entry for #8625
JPS v1 required hosting partners perform a lot of integration work setting up oAuth and then integrating in our APIs. We tried to simplify this as much as possible in JPS v2 by shipping two shell scripts that handle provisioning and cancellation of plans.
But, there are cases where a host may actually want to call the API instead of running a CLI command. For example, what if the site is already gone by the time the CLI command can be run?
It's currently pretty straightforward to cancel a plan by making calls directly to the API. A hosting partner simply needs to get an access token then call the cancellation endpoint, passing the domain and access token. That process is what is documented in this PR.
Provisioning a plan via calls directly to the API is much less straightforward. Currently, we require details such as the blog ID to be passed with the plan provisioning call, things that are better handled via the CLI.
For now, provisioning a plan is marked as TBD while we consider how to approach that.
To test:
Changelog entery