Helm CONNECT API Overview and Policies

API Overview

Thank you for using the Helm CONNECT APIs, other developer services, and associated software (collectively, “APIs”). By accessing or using our APIs, you are agreeing to the policies below. If there is a conflict between these policies and additional policies applicable to a given API, the additional terms will control for that conflict. These policies control your relationship with us so please read them carefully.

Helm CONNECT exposes a public API for end users so they can access their data and extend application functionality. The API is a RESTful architecture, which has web resources identified by Uniform Resource Identifiers (URIs). The API endpoints are accessed with standard HTTP communication and verbs. Data returned from the API is in JSON format.

Compatibility Policy

Wherever possible, Helm will maintain API resources and their representations in a backward compatible manner.

If it is necessary to change a representation in a way that is not backward compatible, Helm will create a new API using the new representation and maintain the old API in accordance with our deprecation policy.

Helm may change the behavior of an API without warning if the existing behavior is incorrect or constitutes a security vulnerability.

Deprecation Policy

Consumers should refer to this API deprecation policy in addition to any other relevant Helm deprecation policies. When there is a conflict between policies, the most restrictive policy will be followed.

Helm will provide reasonable notice, through all relevant communication channels, of new deprecations to publicly accessible APIs. Any deprecated API will be available in its original form for at least six months, UNLESS the existing behavior is incorrect or constitutes a security vulnerability.

Best Practices

Here are some best practices to help you work with the Helm CONNECT APIs:

• Use bursting sparingly and selectively. Bursting is the act of allowing a specific client make many API requests in a short period of time. This is usually done in response to exceptional scenarios, such as cases where your application needs to handle more traffic than usual.

• Use a client side rate limiter. A client side rate limiter sets an artificial limit so that the client in question can only use a certain amount of quota.

• Use exponential backoff to progressively space out requests.

• Avoid short polling, where your clients continuously make requests to the server without waiting for a response. If you short poll, it will be more difficult to catch bad requests even if they do not return useful data.