The Third Iron API provides access to some of the functionality that powers the BrowZine application to allow customers to better integrate their systems with BrowZine, including providing context-aware linking into BrowZine as well as surfacing BrowZine information within other systems. It is a RESTful API, and so functions are accessed by submitting simple HTTP requests against the HTTP resources described in this document. Access to the BrowZine API functions is governed through the use of OAuth 2 Bearer tokens, and API client request rates are limited as described in the Rate Limiting section to avoid inadvertent overloading of our system. The API is available only over HTTPS to protect our customer's data and responses are all of Content-Type "application/json; charset=utf-8".
Our publicly available API accepts OAuth2 Bearer tokens to control access to functions and data of the API. These tokens are valid for an indefinitely long period of time, although Third Iron may temporarily disable a token to protect our systems if we detect suspicious traffic. Should we do so, Third Iron will notify your organization of the action taken and work with your team to resolve the issue. If you believe that your token may be compromised and may be in use by unauthorized parties to access your organization's data, please contact our support team so we may revoke the compromised token and provide you with a new one for your application to use.
Registration and API token provisioning
To register your application for API use and request an API token, contact our support staff at email@example.com
Use of API tokens:
In order to access API functions, your application will have to include the issued token on each request. In conformance with the specification, you may:
Submit the token as part of an Authorization header as shown:
Submit the token as the access_token querystring parameter as shown:
If your request fails to provide any token when making a request against a function that requires one, the API will respond with an HTTP 401 response with an WWW-Authenticate header specifying that the resource is expecting a bearer token.
If your request provides a token that is not recognized by the system (perhaps due to being reported as compromised and revoked), the API will respond with an HTTP 401 response with an WWW-Authenticate challenge header that reports an invalid_token error, with error_description holding additional information about why the submitted token is invalid and a response body that also contains the error and error_description.
Similarly, if your token has been temporarily disabled due to suspicious activity, the API will also respond with an HTTP 401 response reporting an "invalid_token" error.
If your request provides a valid token, but that token does not provide access to the function you are attempting to access, the API will respond with an HTTP 403 response. The body of the response will contain an error of "insufficient_scope" and an error_description that provides additional information about why your token does not provide access to the requested function. Your application should not retry the request. Should your application receive a 403 error, you should check and verify that you are submitting the correct token and that you are accessing the intended API resource. If you believe your token should have access to the resource and your application is receiving this response in error, please contact Third Iron Support at firstname.lastname@example.org so that we may work with you to resolve the issue.
If you believe your API token has been compromised and someone may use it for unauthorized access to your organization's data, please contact Third Iron Support email@example.com so we may revoke the compromised token and issue your application a new one.
Our API imposes limits on its use. Each registered client is allowed a certain number of requests during a specific interval of time. At the end of that period of time, the client's balance of requests is refreshed to the maximum allowed for the interval.
Standard Rate Limit Policy
Unless your application has a special agreement with Third Iron, it will be permitted to perform X requests within an interval of Y seconds. If these limits don't meet your application's needs, please contact us at firstname.lastname@example.org and we can probably work something out.
Every API request should respond with headers to assist your application in understanding what limits are imposed upon it and what it needs to do to stay within limits. Each response will include the headers described in the table below:
|X-RateLimit-Limit||number||Specifies how many requests your application is allowed to make during each reset interval according to the policy applicable to your application|
|X-RateLimit-Remaining||number||The number of requests remaining for the current refresh interval. Should this reach zero, the API will begin to emit HTTP 429 Error Responses|
|X-RateLimit-Reset||number||The time at which your application's remaining requests will reset to the limit, represented in Unix epoch time|
Rate Limit Exceeded Error
Should your application reach its limit, the API will respond with an HTTP 429 error. The response will have a Retry-After header whose value is the number of seconds your application needs to wait before submitting more requests. The body of the error response should hold a JSON error object with error property of "rate_limit_exceeded", an error_description property with more detail about the error, and a retry_after property that also holds the number of seconds your application needs to wait before submitting more requests.