Internal Capability Requests

Create capability request on a merchant's behalf (S2S only)

Creates a capability request for the account named in account_id. Takes the same body as POST /v1/requests — JSON, or multipart/form-data with a payload part plus files_<purpose> parts — and applies the same validation, duplicate check and activation precondition. Per-product kyb_data rules, document purposes and upload limits are in the Capability requests API guide; the two internal-only products' shapes are in the request body below.

This is where PayMongo opens the two requests that are part of activating an account, and which a merchant does not open themselves: prd_svc_paymongo_account_activation and prd_svc_paymongo_std_wallet. Neither needs the account to be activated first.

Which account. An S2S token carrying an account_id claim creates the request for that account, and the body's account_id is ignored. Otherwise account_id in the body is required.

Status the request is created in. prd_svc_paymongo_account_activation is created submitted. prd_svc_paymongo_std_wallet is created draft: the wallet upgrade and profile write already happen at create time. Every other product is created as POST /v1/requests describes.

request_type values: onboarding (every product except account update — what every current caller sends), account_update (prd_svc_paymongo_account_update), and product_request / config_update, which are accepted but sent by nobody today and are not documented publicly.

request_type is not validated against product_code, but assignee-group permissions are granted per (request_type, product_code) pair — a value nobody holds a permission for leaves the request unassignable.

Unlike the public endpoint, the response carries the ops-only fields (requester_id, assignee_email, internal_note, kam_ids, changes).

post/v1/internal/requests

Request

  • Base URL
    https://api.paymongo.com
  • URL
    https://api.paymongo.com/v1/internal/requests
  • Auth
    HTTP bearer

Request body

account_idstring

AccountID is the account the request belongs to. On create, a merchant key is locked to its own account and any value sent here is ignored; service-to-service callers have no bound account and must supply it.

product_code'prd_svc_paymongo_account_activation' | 'prd_svc_paymongo_card_visa_mastercard' | 'prd_svc_paymongo_ewallet_gcash' | 'prd_svc_paymongo_ewallet_grabpay' | 'prd_svc_paymongo_ewallet_maya' | 'prd_svc_paymongo_ewallet_shopeepay' | 'prd_svc_paymongo_std_wallet' | 'prd_svc_paymongo_tax_document' | 'prd_svc_paymongo_account_update' required

ProductCode is what is being asked for. Every product code is accepted here, including the two that are not part of the public contract: prd_svc_paymongo_account_activation and prd_svc_paymongo_std_wallet.

request_type'account_update' | 'config_update' | 'onboarding' | 'product_request' required

RequestType classifies the request; it follows from product_code. Nothing branches on it.

requester_idstring required

RequesterID identifies who initiated the request. Caller-supplied. Required, but not validated for shape and not used for authorization.

Example request

{
  "account_id": "acct_01hzy8n3k2b5xq9m4p7r6t8w1v",
  "kyb_data": {
    "business_type": "corporation",
    "is_one_person_corporation": false,
    "business_legal_name": "Acme Trading Corporation",
    "business_trade_name": "Acme"
  },
  "product_code": "prd_svc_paymongo_account_activation",
  "request_type": "onboarding",
  "requester_id": "org_01hzy8n3k2b5xq9m4p7r6t8w1v"
}

Response

OK

has_moreboolean

Example response

{
  "data": {
    "account_id": "acct_01hzy8n3k2b5xq9m4p7r6t8w1v",
    "id": "req_01hzy8n3k2b5xq9m4p7r6t8w1v",
    "product_code": "prd_svc_paymongo_ewallet_gcash",
    "request_type": "onboarding",
    "requester_id": "org_01hzy8n3k2b5xq9m4p7r6t8w1v"
  }
}

Changes

No recorded changes to this operation across all 1 revision of this API.