-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MyCreate Platform API #453
Open
Juma-creator
wants to merge
1
commit into
pi-apps:master
Choose a base branch
from
Juma-creator:patch-5
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Platform API The platform API allows you to read and write data to the Pi Servers related with your app deployed on the Pi App Platform, and your app's users. ## Overview ### Base path: The latest version of the Platform API is available at `api.minepi.com/v2`. > **Note about API versioning:** > > The platform API is currently in v2. > As much as possible, we will not make any breaking changes to a version of an API, and only release breaking changes as > new major versions. However, we might make breaking changes to an existing version without notice, if those are > necessary (e.g security or privacy fixes). ### Authorization The Platform API supports two different authorization mechanisms. #### Access token authorization Some API calls require that you provide a user's access token to access the resource. They are generally related with a user's data (e.g: `/me`). Those endpoints can be accessed using the following Authorization header: ``` Authorization: Bearer <user access token> ``` Those endpoints can be indifferently accessed from your backend / server app, or from your frontend / client app. #### Server API Key authorization For various reasons, some API calls must be made from your backend / server app. Those endpoints can be accessed using the following Authorization header: ``` Authorization: Key <your Server API Key> ``` > **Warning: Server API keys are for servers only** > > Your Server API Key **must** be kept on your server, and must not be sent to clients (do not use it in your > client javascript code). > In the future, your server API key might enable sensitive operations on your app itself that your users should > not be allowed to perform. Letting users access your server API key is a **serious security breach**. ## API Reference ### Authentication #### Access a user's resource: Retrieve the user's information, including user information limited to what the user has consented to share with your app. ``` GET /me ``` - Authorization method: **Access token** - Response type: [UserDTO](#UserDTO) Verify the data obtained with the frontend SDK (a malicious user could tamper with the requests and send you wrong data) by sending the user’s access token to your backend and using this API endpoint to verify the token validity and the user’s identity. Access tokens are long, random strings, and the request will fail (401 HTTP error code) if the token has been tampered with (a tampered token would not belong to any real user). ### Payments There are two different payment types. 1. U2A (User-To-App) 2. A2U (App-To-User) #### Create a payment (U2A): If a payment type is U2A, use `createPayment` method of the client-side Javascript SDK to create a payment. You can refer to [Payments](./SDK_reference.md#payments) section for more details. #### Create a payment (A2U): ``` POST /payments ``` - Authorization method: **Server API Key** - Response type: [PaymentDTO](#PaymentDTO) Example request body: ``` { "payment": { "amount": 1, "memo": "From app to user test", "metadata": {"test": "test metadata"}, "uid": "a1111111-aaaa-bbbb-2222-ccccccc3333d" } } ``` #### Get a payment: Get information about a payment. ``` GET /payments/{payment_id} ``` - Authorization method: **Server API Key** - Response type: [PaymentDTO](#PaymentDTO) #### Approve a payment: Server-side approval: mark a payment as approved, enabling the user to submit the transaction to the blockchain. ``` POST /payments/{payment_id}/approve ``` - Authorization method: **Server API Key** - Response type: [PaymentDTO](#PaymentDTO) #### Complete a payment: Server-side completion: mark a payment as completed by proving to the Pi Servers that your app has obtained the payment's txid, enabling the user to close the payment flow. ``` POST /payments/{payment_id}/complete ``` - Authorization method: **Server API Key** - Response type: [PaymentDTO](#PaymentDTO) Example request body: ``` { "txid": "7a7ed20d3d72c365b9019baf8dc4c4e3cce4c08114d866e47ae157e3a796e9e7" } ``` #### Cancel a payment: Mark the payment as cancelled. ``` POST /payments/{payment_id}/cancel ``` - Authorization method: **Server API Key** - Response type: [PaymentDTO](#PaymentDTO) #### Get incomplete server payments: Returns the list of server payments (i.e A2U payments) which are in EITHER one of the two states below: - payment created, but no blockchain transaction was made yet ; - blockchain transaction submitted, but the payment has not been completed by the developer. ``` GET /payments/incomplete_server_payments ``` - Authorization method: **Server API Key** - Response type: { "incomplete_server_payments": Array<[PaymentDTO](#PaymentDTO)> } ### Ads #### Verify a rewarded ad status Verify status of a rewarded ad by `adId` returned by client Pi SDK method `displayAd('rewarded')` ``` GET /ads_network/status/:adId ``` - Authorization method: **Server API Key** - Response type: [RewardedAdStatusDTO](#RewardedAdStatusDTO) ## Resource types ### `UserDTO` ```typescript { uid: string, // An app-specific user identifier credentials: { scopes: Array<Scope>, // a list of granted scopes valid_until: { timestamp: number, iso8601: string } }, username?: string, // The user's Pi username. Requires the `username` scope. } ``` ### `PaymentDTO` ```typescript { // Payment data: identifier: string, // payment identifier user_uid: string, // user's app-specific ID amount: number, // payment amount memo: string, // a string provided by the developer, shown to the user metadata: Object, // an object provided by the developer for their own usage from_address: string, // sender address of the blockchain transaction to_address: string, // recipient address of the blockchain transaction direction: Direction, // direction of the payment created_at: string, // the payment's creation timestamp network: AppNetwork, // a network of the payment // Status flags representing the current state of this payment status: { developer_approved: boolean, // Server-Side Approval transaction_verified: boolean, // blockchain transaction verified developer_completed: boolean, // Server-Side Completion cancelled: boolean, // cancelled by the developer or by Pi Network user_cancelled: boolean, // cancelled by the user }, // Blockchain transaction data: transaction: null | { // This is null if no transaction has been made yet txid: string, // id of the blockchain transaction verified: boolean, // true if the transaction matches the payment, false otherwise _link: string, // a link to the operation on the Blockchain API }, }; ``` ### `RewardedAdStatusDTO` ```typescript { "identifier": string; // the adId token returned from the Pi SDK displayAd("rewarded") method "mediator_ack_status": "granted" | "revoked" | "failed" | null; "mediator_granted_at": string | null; // ISO 8601 date string "mediator_revoked_at": string | null; // ISO 8601 date string } ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Platform API
The platform API allows you to read and write data to the Pi Servers related with your app deployed on the Pi App Platform, and your app's users.
Overview
Base path:
The latest version of the Platform API is available at
api.minepi.com/v2
.Authorization
The Platform API supports two different authorization mechanisms.
Access token authorization
Some API calls require that you provide a user's access token to access the resource. They are generally related with a user's data (e.g:
/me
). Those endpoints can be accessed using the following Authorization header:Those endpoints can be indifferently accessed from your backend / server app, or from your frontend / client app.
Server API Key authorization
For various reasons, some API calls must be made from your backend / server app. Those endpoints can be accessed using the following Authorization header:
API Reference
Authentication
Access a user's resource:
Retrieve the user's information, including user information limited to what the user has consented to share with your app.
Verify the data obtained with the frontend SDK (a malicious user could tamper with the requests and send you wrong data) by sending the user’s access token to your backend and using this API endpoint to verify the token validity and the user’s identity.
Access tokens are long, random strings, and the request will fail (401 HTTP error code) if the token has been tampered with (a tampered token would
not belong to any real user).
Payments
There are two different payment types.
Create a payment (U2A):
If a payment type is U2A, use
createPayment
method of the client-side Javascript SDK to create a payment. You can refer to Payments section for more details.Create a payment (A2U):
Example request body:
Get a payment:
Get information about a payment.
Approve a payment:
Server-side approval: mark a payment as approved, enabling the user to submit the transaction to the blockchain.
Complete a payment:
Server-side completion: mark a payment as completed by proving to the Pi Servers that your app has obtained the payment's txid, enabling the user to close the payment flow.
Example request body:
Cancel a payment:
Mark the payment as cancelled.
Get incomplete server payments:
Returns the list of server payments (i.e A2U payments) which are in EITHER one of the two states below:
Ads
Verify a rewarded ad status
Verify status of a rewarded ad by
adId
returned by client Pi SDK methoddisplayAd('rewarded')
Resource types
UserDTO
PaymentDTO
RewardedAdStatusDTO