Migrating developers to monetization

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

If you have existing developers that you need to migrate to Monetization:

  1. Create the API products, API packages, and rate plans for the developers that you are migrating, if they don't already exist. For more information, see:
  2. Publish the rate plans, as described in Publishing rate plans.
  3. Add the new developers to your organization, as described in Register app developers.
  4. Top up the prepaid balance for each developer, as described in Manage prepaid account balances.
  5. Accept the rate plan, as described in Purchase rate plans using the API.

    Note: To waive the set up fees, if a developer has already been charged, set the waivefees query parameter to true.

  6. If a developer that you are migrating has existing transactions, you can manually transfer the transaction usage using the following resource:
    /organizations/{org_name}/transactions, where {org_name} is the name of the organization.

    Note: If a developer does not have existing transactions, you can skip this step.

    The transactions resource inserts a single transaction that reflects the current transaction usage and updates all internal counters to reflect this new value.

    For example, if the developer has issued 1000 calls to the API prior to the migration, to capture the current activity you can set the transaction usage to 1000 by calling the transactions resource and setting the batchSize property to 1000 in the request body.

    The following table summarizes the configuration properties that you can specify in the request body to manually set the number of transactions, their default values, and whether or not they are required.

    Property Description Default Required?
    application

    ID of the developer app.

    		 N/A Yes
    batchSize

    Number of transactions that you want to transfer.

    		 1 No
    custAttn

    Value of the custom attribute that is used with batchSize to calculate the transaction usage.

    The custom attribute number in the message must be specified as a positive whole or decimal (up to four decimal places) value. Negative values are not allowed.

    The custom attribute must be defined in:

    		 N/A Yes
    product

    ID of the API product.

    		 N/A Yes
    type

    Must be set to CHARGE (which is the default).

    		 CHARGE No

    To skip validation steps and forcibly set the number of transactions, set the force query parameter to true (for example, ?force=true). By default, ?force=false and validation steps are executed. For example, if a prepaid developer has a zero balance and activity on the account is suspended, if ?force=false the request will fail during validation.

    For example, the following request sets the number of transactions to 50 for the specified application and API product:

    $ curl -H "Content-Type:application/json" -X POST -d \
'{ 
   "application":{
     "id":"6a9b1afc-2110-43d6-bae7-1b137aecb05b"
   },
   "product":{
     "id":"testproduct"
   },
   "batchSize":50
}' \
"https://api.enterprise.apigee.com/v1/mint/organizations/myOrg/transactions" \
-u email:password

    The following request sets the transaction usage to 12.5 for the specified application and API product. In the request, batchSize is set to 125 and the value for the first custom attribute defined for the API product is set to 0.1. When multiplied together, 125 * 0.1 is 12.5.

    $ curl -H "Content-Type:application/json" -X POST -d \
'{ 
   "application":{
     "id":"6a9b1afc-2110-43d6-bae7-1b137aecb05b"
   },
   "product":{
     "id":"testproduct"
   },
   "batchSize": 125,
   "custAtt1" : 0.1
}' \
"https://api.enterprise.apigee.com/v1/mint/organizations/myOrg/transactions" \
-u email:password
  7. If a developer has not been charged the necessary setup or recurring fees, you can manually charge a setup or recurring fee for a rate plan using the following resource:
    /organizations/{org_name}/transactions, where {org_name} is the name of the organization.

    Note: If the developer has already been charged setup or recurring fees, you can skip this step. Calling the transactions resource will not impact setup or recurring fees defined by the rate plan.

    The following table summarizes the configuration properties that you can specify in the request body to manually charge a setup or recurring fee for a rate plan, their default values, and whether or not they are required.

    Property Description Default Required?
    currency

    Currency used for the rate plan. Specify the ISO 4217 code for the currency, such as usd for United States dollar or chf for Swiss franc.

    		 N/A Yes
    developer

    ID of the developer.

    		 N/A Yes
    rate

    Setup or recurring fee to charge.

    		 N/A Yes
    ratePlan

    ID of the rate plan.

    		 N/A Yes
    type

    Set to SETUPFEES or RECURRINGFEES.

    		 CHARGE Yes

    To skip validation steps and forcibly charge the fee, set the force query parameter to true (for example, ?force=true). By default, ?force=false and validation steps are executed. For example, if a prepaid developer has a zero balance and activity on the account is suspended, if ?force=false the request will fail during validation.

    For example, the following request charges a setup fee of 10 in US dollars to the developer subscribed to the rate plan:

    $ curl -H "Content-Type:application/json" -X POST -d \
'{ 
   "developer":{
     "id":"dev1@myorg.com"
   },
   "currency":{
     "id":"usd"
   },
   "ratePlan":{
     "id":"mypackage_rateplan1"
   },   
   "rate":10,
   "type":"SETUPFEES"
}' \
"https://api.enterprise.apigee.com/v1/mint/organizations/myOrg/transactions" \
-u email:password