NATS API Best Practices

From TMM Wiki
Jump to navigationJump to search
NATS 4
Members Admin
The Members Admin
View Member Details
Add Member
MySQL Auth
Mod Authn DB
Multisite Access
Member Logging
Member Password Retrieval
OpenID Connect
Mod Auth OpenIDC
ID Numbers
SOAP API
API
API Best Practices
WSDL Cache
Add Affiliate
Add Member Note
Admin Get Adtools
Adtool Categories
Adtool Types
Affiliate Get Campaigns
Bulk Import Adtools
Caching
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_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
Ping
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
REST API
API Overview
API Best Practices
REST API PATH UPDATES
Adtools
GET /adtools/admin
GET /adtools/categories
GET /adtools/types
POST /adtools/importdump
Affiliate
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
Member
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
Option
GET /option/options
GET /option/rule
PATCH /option/rule
PATCH/option/text
POST /option/rule
Payments
GET /payments/getpayments
GET /payviarule
PATCH /payments/setstatus
PATCH /payviarule
Report
GET /profitlossreport
Get /transactionpayouts
GET /report/transaction
Service
GET /service/decodenatscode
GET /service/ping
POST /service/sendemail
Please note: This information is best represented on NATS versions higher than 4.1.16.1


This article 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 the SOAP API in NATS is deprecated and included only for backward compatibility.

Restrict Access by IP Address

In order to use the NATS API, you will need to provide a list of IP addresses will be granted access to the NATS API. In the "Security" section of the Configuration Admin, this information is stored as a comma separated list of IP addresses set in the "ADMIN_API_ALLOWED_IPS" variable. We recommend that you grant access to only the IP addresses of those who will be actively using the NATS 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 API access to IP addresses, you will need to enable the NATS API itself. In the the "Security" section of the Configuration Admin, turn on the API by checking the box for the "ENABLE_SOAP_API" or "ENABLE_REST_API" settings, depending on which system you plan to use. This configuration is disabled by default, and is available to provide a way for you to quickly turn off both the NATS API to all users should the need arise. We recommend enabling only the API systems you plan to use.

In the "Security" section of the Configuration Admin, check the ENABLE_SOAP_API or ENABLE_REST_API settings depending on your use.

API Users per System or Server

We recommend creating separate API accounts for separate uses or servers. This makes it so access to the API systems are limited should that account be compromised. An example of this type of set up would be creating an account for API use in your members area, and creating a separate account for API use on an external Adtool system. If you have members areas on separate servers, it would be best to create a separate account for each 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 make available only those systems that an account needs to use. We encourage you to only make available the functions or resources that are necessary to the account itself. For example, if an account is to be used for membership authentication, set the account's API permissions to only allow them access to the member search function.

SOAP API Permissions

By default, an account has access to all available SOAP API functions, and you have the ability to disable any functions that are not necessary for the 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" buttons to move the selected functions from one column to the other. You can also use the "Auto Check:" links to quickly check "All" or "None" of the functions, or "Invert" your selection before Enabling or Disabling functions.


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

REST API Permissions

By Default, an account does not have access to any of the available REST API resources. Use the check boxes in the "Enabled" column to select which of the collection, method, and resource combinations you would like to Enable for the 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, whereas the Collection of "Adtool" and Method/Resource set to ANY will give the account access to all functions available only in the "Adtool" collection.


REST API permissions allow you to set available collections/resources/methods per account.


Examples of API Settings

Membership Authentication API Account

This is an example configuration for an account to be used for membership authentication through a restricted members area. The image on the left shows the SOAP API permissions for this account with access to only the following functions: get_member_details, record_member_login, and set_member_details. The image on the right shows the account set to the equivalent 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 Member Authentication Account Example REST API Member Authentication Account Example

Members Area Across Multiple Servers

If you have members areas across multiple servers, we recommend utilizing a separate API account for each server as shown in this example.

API PERM WIKI SCREEN 08.png