Best Practices

Please follow these guidelines when using the Pricing and Availability API

Rate Limiting

Arrow currently does not institute per-hour, per-minute, and per-IP rate limits for each API method, but abuse will result in revocation of credentials. Our default limits are more than sufficient for nearly all use cases.

Caching

Caching data is a violation of the API Terms of Use, and will result in revocation of your credentials.

API Key / Login / OAuth

To ensure the security of your API key and/or OAuth access token, we strongly suggest that you make requests to the Arrow API server-side whenever possible.

Any requests to the Arrow API made via client-side Javascript present the risk of your OAuth token or API key / Login being compromised, but there are steps you can take to partially mitigate this risk. Most importantly, never include your apikey or access_token inline in the page. Keep any references to your apikey or access_token in code that is contained in external javascript files which are included in the page. For additional security, don't have the key or token itself contained anywhere in your javascript code, but rather make an ajax call to load it, and keep it in a variable stored in a privately scoped method.

HTTP Response Status Codes

Please note that all valid responses in json and xml format will carry an HTTP Response Status Code of 200. This means that invalid, malformed or rate-limited json and xml requests may still return an HTTP response status code of 200. In json and xml responses, within the transactionArea, the succes and returnMsg values indicate whether a request is well formed and valid.

Batch Processing

The Arrow API supports searching multiple parts with a single API call. Up to 100 parts can be handled in one API call using the search/list endpoint.

Search Token

In previous versions of the Pricing and Availability API, the search token was attached to the path of the endpoint. The search token should always be passed as a parameter using search_token

Wildcard Searches

Wildcard searches are not allowed. Please contact us with your specific needs.

URL Encoding

All part numbers to the Pricing and Availability API must be URL encoded, even if these parts already contain escaped characters. For more information about URL encoding, see http://www.w3schools.com/tags/ref_urlencode.asp.

For example, the part RMC-1/8-1K-1% should be fully escaped to RMC-1%2F8-1K-1%25

Most languages include a function for URL encoding, including urlib.quote() in Python, encodeURIComponent() in javascript, and urlencode() in PHP.