anchor.diff:  out from underneath the client app developers who are using it.
   
   ==== APIs
  -an API represents an external API that is being governed by the API management system. an API consists
  +An API represents an external API that is being governed by the API management system.  An API consists
   of a set of metadata including name and description as well as an external endpoint defining the API
  -implementation. The external API implementation endpoint includes the type/protocol and the actual endpoint
  -location so that the API can be properly proxied to at runtime.
  +implementation. The external API implementation endpoint includes:
  +
  +* The type/protocol of the endpoint (e.g. REST or SOAP)
  +* The endpoint content type (e.g. XML or JSON)
  +* The endpoint location (URL) so that the API can be properly proxied to at runtime.
   
   In addition, policies can be configured on an API. Typically, the policies applied to APIs are things
  -like authentication.  Any policies configured on API will be applied at runtime regardless of the
  +like authentication, or caching.  Any policies configured on API will be applied at runtime regardless of the
   client app and API contract.  This is why authentication is a common policy to configure at the API
   level.
   
  -APIs must be offered through a valid plan configured in the same organization. API consumers must
  -consume the API through one of those plans. Please see the section on 'API Contracts' for more
  -information.
  -
  -TIP: Note that, alternatively, APIs can be marked as "Public", which means they (once published) can be
  -used by any client, without needing a Contract.  To use a public API, simply send requests to the
  -appropriate managed endpoint (through the API Gateway) without providing an API Key.
  +APIs may be offered through one or more plans configured in the same organization. When plans are used,
  +API consumers (client apps) must consume the API through one of those plans. Please see the section on
  +'API Contracts' for more information.  Alternatively, an API can simply be marked as "Public", in which
  +case any client may access the API's managed endpoint without providing an API Key.
   
   Only once an API is fully configured, including its policies, implementation, and plans can it be
  -published to the runtime gateway for consumption by client apps.  Once this is done, the API cannot be
  -changed. If changes are required, a new version of the API must be created and configured.
  +published to the Gateway for consumption by client apps.  Once an API has been published, it can only
  +be changed if it is a "Public" API.  APIs that are offered via Plans are immutable - to change them
  +you must create a new version.  The reason for this is that API consumers may have created Contracts
  +with your API, through your Plan.  When they do this, they must agree to some terms and conditions.
  +It is therefore understood that the terms to which they are agreeing will not change.  However, for
  +Public APIs, there is no such agreement.  For this reason, you can make changes to Public APIs and
  +re-publish them at any time.
   
   ==== Client Apps
   A client app represents a consumer of an API. Typical API consumers are things like mobile applications and
   B2B applications. Regardless of the actual implementation, a client app must be added to the
  -API management system so that contracts can be created between it and the APIs it wishes to consume.
  +API management system so that Contracts can be created between it and the APIs it wishes to consume.
   
   A client app consists of basic metadata such as name and description.  Policies can also be configured on
   a client app, but are optional.
   
  -Finally, API contracts can be created between a client app and the API(s) it wishes to consume.
  -Once the API contracts are created, the client app can be registered with the runtime gateway. Once this
  -registration is complete, the client app can no longer be altered.  If changes are required, a new version
  -of the client app must be created and configured.
  +Finally, API Contracts can be created between a client app and the API(s) it wishes to consume.
  +Once the API Contracts are created, the client app can be registered with the runtime gateway.  Policies
  +and Contracts can be added/removed at any time.  However, after any changes are made, you must
  +re-register the client app.
   
   ==== API Contracts
  -an API contract is simply a link between a client app and an API through a plan offered by that
  +An API contract is simply a link between a Client App and an API through a plan offered by that
   API. This is the only way that a client app can consume an API. If there are no client apps that
   have created API contracts with an API, that API cannot be accessed through the API management
  -runtime gateway.
  -
  -When an API contract is created, the system generates a unique API key specific to that contract. All
  -requests made to the API through the API Gateway must include this API key. The API key is used to create
  -the runtime policy chain from the policies configured on the API, plan, and client app.
  +runtime gateway (unless of course the API is "Public").
  +
  +When an API Contract is created, the system generates a unique API key specific to that contract. All
  +requests made to the API by a Client App through the API Gateway must include this API key. The API
  +key is used to create the runtime policy chain from the policies configured on the API, plan, and
  +client app.
   
   API Contracts can only be created between Client Apps and published APIs which are offered through
  -at least one Plan.  an API Contract cannot be created between a Client App and a public API.
  +at least one Plan.  An API Contract cannot be created between a Client App and a Public API.
   
   ==== Policy Chain
   A policy chain is an ordered sequence of policies that are applied when a request is made for an API
  
positive.code: 
  === Consuming APIs
  After the API providers have added a number of APIs to the API management system, those APIs
  can be consumed by client apps. This section explains how to consume APIs.
  
  ==== Consuming Public APIs
  If you have marked an API as "Public", then consuming it is a simple matter of sending a request to the
  
negative.code: user can take within an organization.
  
  ==== New Users
  Users must self register with the management UI in order to be given access to an organization or to
  create their own organization. In some configurations it is possible that user self registration is
  unavailable and instead user information is provided by a standard source of identity such as LDAP.  In
  either case, the actions a user can take are determined by that user's role memberships within the context
  of an organization.
  
  ==== Membership
  Users can be members of organizations. All memberships in an organization include the specific roles the
  user is granted. It is typically up to the owner of an organization to grant role memberships to the members
  of that organization.
  
  