NATS API Best Practices

From TMMwiki
Jump to: navigation, search
Members Admin
The Members Admin
View Members Details
Add Member
MySQL Auth
Mod Authn DB
Multisite Access
Member Logging
Member Password Retrieval
ID Numbers
API Best Practices
WSDL Cache
Add Affiliate
Add Member Note
Admin Get Adtools
Adtool Categories
Adtool Types
Affiliate Get Campaigns
Bulk Import Adtools
Decode Natscode
Expire Manual Member
Get Affiliate Campaigns
Get Affiliate Hit Data
Get Affiliate Loginids
Get Affiliate Nats Codes
Get Affiliate Payout
Get Affiliate Program Campaign List
Get Member Details
Get Member Instant Upgrade String
Get Member Package Upgrade String
Get Member Token Rebuy String
Get Member Upsell String
Get Payment Data
Get Payvia Rule
Get Profit Loss Report
Record Member Login
Search Affiliate Info
Search Member Info
Send Email API Function
Set Affiliate Admin Settings
Set Affiliate Customs
Set Affiliate Defaults
Set Affiliate Information
Set Affiliate Settings
Set Member Details
Set Payment Status
Set Payvia Rule
API Overview
API Best Practices
GET /adtools/admin
GET /adtools/categories
GET /adtools/types
POST /adtools/importdump
GET /affiliate/campaigns
GET /affiliate/hitdata
GET /affiliate/payout
GET /affiliate/searchinfo
POST /affiliate/addaffiliate
POST /affiliate/invoice
PATCH /affiliate/setadminsettings
PATCH /affiliate/setcustoms
PATCH /affiliate/setdefaults
PATCH /affiliate/setinformation
PATCH /affiliate/setpayviainfo
PATCH /affiliate/setsettings
PATCH /affiliate/status
GET /member/authstring
GET /member/details
GET /member/searchinfo
GET /suggestedcanceloffers
PATCH /member/setdetails
PATCH /member/setexpiration
POST /member/addnote
POST /member/recordlogin
PUT /member/expiremanual
PATCH /member/forget
GET /option/options
GET /option/rule
PATCH /option/rule
POST /option/rule
GET /payments/getpayments
GET /payviarule
PATCH /payments/setstatus
PATCH /payviarule
GET /profitlossreport
Get /transactionpayouts
GET /report/transaction
GET /service/decodenatscode
GET /service/ping
POST /service/sendemail

Please note: This information is best represented on NATS versions higher thatn

The following lists out several best practices for using the NATS API. These practices are encouraged in order to prevent unwanted access to processes within NATS that would otherwise not be available unless logged in. We encourage you to use the REST API system rather than the SOAP API system as we are deprecating the SOAP API system in NATS.

Restrict Access by IP Address

In the configuration admin under the "Security" section, you are able to make use of the API you will need to provide a list of IP addresses who will have access to the NATS API. This information is set as a comma separated list of IP addresses set in the "ADMIN_API_ALLOWED_IPS" variable. We recommend that you put the IP addresses of only those who will be actively using the API itself.

In the "Security" section of the Configuration Admin, set the ADMIN_API_ALLOWED_IPS configuration to limit the IPs that are able to use the API.

API ON/OFF switch

In addition to allowing only certain IP addresses you will need to turn the API itself on. In the configuration under the "Security" section, turn on the API by checking the box for "ENABLE_SOAP_API" or "ENABLE_REST_API" depending on which system you are planning on using. This configuration is turned off by default and allows you to quickly turn off both the SOAP and REST API to all users should the need arise. We recommend having only the API system you plan to use be enabled.

In the "Security" section of the Configuration Admin, set the ADMIN_API_ALLOWED_IPS configuration to limit the IPs that are able to use the API.

API Users per System or Server

We recommend having separate API Accounts for separate uses or servers. This makes it so access to the API systems are limited should that account be compromised. Examples of this type of set up would be having one account to be used within your members area, while another account be used on an external Adtool system. If you have members areas on separate servers it would be best to have an account per server as well.

We recommend having separate accounts for specific API purposes.

API Permissions

For each account able to access the API system, we provide the ability to restrict the resources or functions available to them. The permissions system allows you to only make available those systems that the account would use. We encourage you to only make available those functions or resources that are necessary to the account itself. If the account is used for Membership authentication, only allow them access to the member search function.

SOAP API Permissions

By default, an account has access to all SOAP API functions available and you are able to disable all those options that are not necessary for that account. Use the check boxes next to each of the functions to select which you wish to make either Enabled or Disabled. Once selected, use the "Disable APIs -->" and "<-- Enable APIs" to move the function from one column to another. You can also use the "Auto Check:" links to quickly check "All", "None", or "Invert" your selection before switching functions to be Enabled/Disabled.

SOAP API permissions allow you to set available functions per account.

REST API Permissions

By Default, an account does not have any access to the available REST API resources available. Use the check boxes in the "Enabled" column to set which of these of the collection, method, and resource combinations is enabled for this Account. Save the configuration by clicking "Save REST API Permissions" at the bottom of the page. Collections, Methods, or Resources set with "Any" allow the Account access to any of the specific option in the combination. For example, Collection/Method/Resource with each option set to "Any" allows the Account access to all REST API functions where as the Collection of "Adtool" and Method/Resource set to "Any" will give the Account access to all functions available only in the "Adtool" collection.

SOAP API permissions allow you to set available functions per account.

Examples of API Settings

Membership Authentication API Account

This example shows the settings that would be set for an account that would be used as a form of membership authentication through a restricted members area. The image on the Left shows the SOAP API permissions for this account only have access to the functions: get_member_details, record_member_login, and set_member_details. The image on the right shows the account set to the equivilant resources. In this example, this account would be used to authenticate, to record the login to NATS, and to allow the update of member information.

SOAP API permissions allow you to set available functions per account. SOAP API permissions allow you to set available functions per account.

Members area across multiple Servers

If you have members areas across multiple servers we recommend utilizeing an account per server as shown in this example.