New APIs may be used when there is no corresponding API in the TMF API Catalogue. It is strongly encouraged that the new API is conformant with the Crowdsourcing recommendations (so that it can be crowdsourced after the Catalyst and added to our existing API Catalog).

In general any non TMF API exposed in a Catalyst or Open Hack should follow the API Crowdsourcing rules as defined in the TMF API Crowdsourcing Template.

In particular:

• Any new exposed API must be complementary to the existing APIs and not a duplicate of the existing APIs.
• If a new API is exposed and use a relationship to an entity already defined in the existing APIs then the embedded (for dependant entitities) or the hyperlink must be relative to that resource definition.
• An API must expose entities (i.e Resources) which can be derived from the TMF Information Framework (when they exist).
• The properties and relationships  exposed by the API Data Model must be be a representation of the entities and relationships described in the TMF Information Framework.
• If the API expose entities which are not derived from the Information Framework reasons for their introduction must be supplied.
• The API must be  compliant with the ODE Data Model Design Patterns best practices (relationship management, event etc...).
• When an API is hyperlinked or use  definitions of entities already defined by other APIs for example when an entity needs to hyperlink to other entities already defined in the TMF APIs they need to use the href model as defined in the TMF REST Guidelines
• New API must be interoperable with other TMF APIs from a functional and non-functional point of view.

Use the following table to identify API’s which are not mappable to existing TMF API’s or are not extensions to existing TMF API’s.

Please identify if they are intended to be contributed to the TM Forum community or will be used as proprietary integration point.

The cells in green are illustrative examples.