Glossary of Terms

Key terminology used in the platform.

access token
See OAuth access token.
alert
A type of Dashboard item designed to inform app or API administrators about an issue such as an SLA (Service Level Agreement) violation.
anonymous user
A user who is browsing the platform without logging in. Anonymous users can see public content but cannot post to Boards, write comments or ratings, or create resources such as apps.
API
A key resource in the Community Platform. An API provides a business with a way of using the Internet to extend business capabilities to connect with new customers in new ways. In this context an API is a Web service exposed outside the enterprise, typically using RESTful design principles, and often with JSON content.
API access request
A specific type of Connection Request. An API access request governs the relationship between an app and an API for the life of the connection. When an app team member requests a connection to an API on behalf of the app, the API administrator is notified of the pending request and can respond accordingly. The administrator can approve or deny the request.
API Administrator
One of the roles defined in the Community Platform is that of the API Admin. Each API must have at least one Admin, and can have more. The API Admin approves or rejects connection requests, moderates the API's Board, views and manages alerts and trouble tickets, and manages documents, policies, and other information associated with the API. The API Admin can also view performance and usage data for the entire API, and can invite others to be Admins for the same API.
API Board
The API Board allows any member to post discussions pertaining to a specific API, or create trouble tickets pertaining to issues associated with the operation of a particular API.
Navigation: APIs > API Name > Board
API Gateway
The SOA Software API Gateway provides service integration and gateway services for APIs. It bundles SOA Software Policy Manager with one or more message handling intermediaries.
app
An app (application) is a piece of software that delivers specific capabilities to its users. In the context of the Community Platform, an app is a piece of software that consumes one or more APIs.
App Board
The App Board allows development team members to create private discussions with other team members pertaining to their specific application development projects. Team members can also create trouble tickets pertaining to issues associated with application development.
Navigation: My Apps > App Name > Board
App ID
When an app developer registers an app in the platform, it is assigned an App ID. The App ID is a unique identifier for your app within the platform. All API calls include the App ID.
app team member
One of the roles defined in the Community Platform is that of the app team member. Each app most have at least one team member and can have more. An app team member initiates contract requests, such as API access requests, moderates the app's Board, and views and manages trouble tickets relating to the app. The app team member can also view performance and usage data for the app's API usage, and can invite others to be team members for the same app. All app team members have the same rights.
authorization endpoint
See OAuth authorization endpoint.
authorization server URL
See OAuth authorization server URL.
bearer token
Used in OAuth, the bearer token is a security token with the property that any party in possession of the token (the bearer) can use it. Using a bearer token does not require proof of possession of cryptographic key material (proof-of-possession).
Board
In the Community Platform, every resource, such as an app or API, has a Board that displays all feed entries for the resource. Users with approved connections to the resource can post items to the resource's Board according to privileges. For example, a member of a specific app team can post items to the Board for that app. Users with approved connections also see relevant Board items in their personal home Feed.
Board item
An individual entry on a resource's Board. A Board item can be an Alert, API Access Request (Contract Request), Discussion, Group Membership Invitation, or Ticket.
bpel file
A bpel file is a Business Process Execution Language file. BPEL itself is an abbreviation for Web Services Business Process Execution Language (WS-BPEL), an OASIS standard executable language which is a standard format for specifying actions within a business process, used by webservices. When the Site Admin or Business Admin creates an export file from the platform, such as an API export file, the export ZIP file (package file) includes BPEL files.
Business Administrator
One of the roles defined in the Community Platform is that of the Business Administrator. A business can own one or more APIs and apps, and must have at least one Administrator. The Business Administrator automatically has administrator rights over all the APIs and apps owned by the business as well as all the users who are part of the business. For more information, see What roles can a Business Administrator perform?
CA SiteMinder
CA SiteMinder® is a popular commercial access management product. The platform supports use of CA SiteMinder for login or for OAuth support.
callback URL
Redirect URL. See OAuth callback URL.
Certificate Authority
A Certificate Authority (CA) issues certificates and guarantees the validity of the binding between the certificate owner and its public key. The CA is a trusted authority, and any certificate issued by the CA identifies the owner of the certificate. Therefore the private key that corresponds to the public key in the certificate is deemed to be known only by the specific owner. Two Certificate Authority options are supported. The Platform Tenant (Host) provides a simplified version of a Certificate Authority that can issue and renew X.509 certificates, or the app developer can import a certificate that was issued outside the platform.
Navigation: My Apps > Details > Security
Connect provider
In OpenID Connect, the identity provider is called the Connect provider.
connection
A relationship between resources in the Community Platform—such as the API access relationship between an app and an API that it's using.
connection request
A workflow process that governs the relationship between two resources for the life of the connection. It is a request to establish a connection between resources; for example, an API access request or a follow request.
connector domain
In the context of the platform, a connector domain is an independent domain that provides authentication services; for example, Google®, Facebook®. Users can log in by authenticating with the connector domain rather than signing up as platform users.
container
An SOA Software container instance performs a specific web service management function in an API Gateway deployment. Instances have a unique Instance Name, Description, and Listener configuration relative to the deployment requirements.
Dashboard
The user's Dashboard, also called home page or feed, is the first page the user sees after logging in. The Dashboard includes information relating to apps and APIs the user is associated with. An individual user's Dashboard is an aggregation of all the Board items from all the resources that the user is following. An individual user can modify the types of information that are displayed on his/her Dashboard. See also Dashboard entry.
Navigation: Dashboard tab.
Dashboard entry/item
An informational item that appears on a user's Dashboard. The entries on a specific user's Dashboard are Board items for resources the user is following. A Dashboard entry can be any of the following: Alert, API Access Request (Contract Request), Discussion, Group Membership Invitation, or Ticket.
deployment zone
If an API is hosted on the platform and using the proxy capability, the API owner can specify the deployment zones, such as a geographical area or a specific data center, that the endpoint will be proxied in.
Dev Console
The Developer Console (Dev Console) is a web-based REST client provided as part of the Community Manager user interface so that developers can test different APIs in the context of their app. It is available for any app added to the platform, on the Apps > Dev Console page.
developer
A developer of an app that will consume an API.
discussion
In the Community Platform, an authorized user can create a discussion topic about a resource (app or API) on the resource's Board. A discussion is typically, but not necessarily, created by someone other than the owner or administrator of the resource. Discussion entries are not threaded; users comment on the original item rather than on the comments/replies to the original item. Users can, however, mark or unmark the discussion itself and/or one or more discussion comments.
Each discussion has a title and one or more comments. The visibility of a discussion is controlled by the visibility of the resource it's associated with; for example, a discussion about a Limited (Private) API can only be seen by administrators and Private API Group members associated with that API.
environment
An API contract can apply either to the Sandbox environment, which is a testing area, or the production environment.
export
A Site Admin or Business Admin can output all the information about one or more of certain resources, or an entire business, to an export file. The information can then be imported into another platform instance. Information is exported to a specially formulated ZIP file called a package file.
Full export is only available to a Site Admin or Business Admin. An API Admin can export an API.
follow request
A specific type of Connection Request used to establish a "follow" relationship between a user and a resource that can be followed. Currently, only apps, APIs, and groups can be followed.
group
1) The term "group" is used in many instances to refer to any of the following types of groups in the Community Platform: app teams, Private API groups, API Administrator groups, Site Administrator groups, or independent groups.
2) "Group" is sometimes used specifically to mean a Private API Group.
HMAC
The HMAC hashing algorithm uses a symmetric key to create a hash for message security. HMAC can be used with cryptographic hash algorithms such as MD5 or SHA-1.
import
When information is exported from one instance of the platform to an export file (package file), it can be imported to another instance of the platform.
Only a Site Admin or Business Admin has permission to perform functions relating to import.
independent group
A group that exists independently of any single app or API. Any authorized user can create an independent group, and becomes the first administrator. The administrator can then invite other members and can remove members and change a member's role. There are three roles; admin, leader, and member. All members can see resources the group is linked to. Admins have full rights over the group.
identity provider
An identity provider (sometimes abbreviated as IdP) is an entity responsible for verifying identity and issuing identity information, usually in the form of a token. A common example is a website that allows users to log in using a Facebook or Google identiy; in this scenario, Facebook and Google are identity providers. In OpenID Connect, the identity provider is called the Connect provider.
invitation status
A value that shows a group member's relationship with the group. When a new member is invited to a group, the member has an initial status of Pending. Depending on the user's response, the status can change to Accepted or Rejected. Other possible status values are: Cancelled, Removed, or Deleted.
JSON
An acronym for JavaScript Object Notation, JSON uses a subset of the JavaScript syntax to describe an object clearly and succinctly. One of the advantages of JSON over XML for API messages is that message content conveyed in the JSON format is much more concise than the same content conveyed in XML, consuming less bandwidth.
leader
In the context of a Private API Group, a leader is a senior group member. A leader can invite additional members to the group and can change another member's status, from member to leader or vice versa.
license
A License is a tailored API access package designed by the Business Admin/API Admin and offered to the app developer. A license includes one or more license terms, each of which can include multiple scopes, giving access to specifically designated operations, and multiple quality of service (QoS) policies, and also one or more legal agreements applicable to the license.
For more information on the License feature, see Licenses: Feature Overview.
license term
A license term defines the access that is being offered in a license (scope) and the level of access (QoS policy). Each license term includes one or more scopes plus, optionally, the quality of service limits/policies to be applied to all scopes in the license term. Scopes apply to both visibility and access; policies apply only to access. To have any impact, a license term must include at least one scope.
mark
Users can give positive feedback to items such as discussion topics and associated comments, reviews, and other resources such as tickets, using the Mark function. Choosing Mark provides positive feedback, in the same way as "Like" in Facebook®. The Mark value toggles on and off, so a user can mark or unmark a discussion comment. In the user interface, the mark icon is a thumbs-up, and the unmark icon is a closed fist.
MAC token
Acronym for Message Authentication Code. Used in OAuth 2.0, the MAC token is a security code that is typed in by the user of a computer to access an account or a portal. The code is attached to the message or request sent by the user. The MAC token attached to the message must be recognized by the receiving system in order to grant the user access. MAC tokens are commonly used in electronic funds transfer (EFT) transactions to maintain information integrity.
member
In the context of a Private API Group, a group member has access to all information relating to the Private API and the group, including tickets and discussions. Members cannot invite additional members or change the status of other members. A member can be promoted to leader status by the API Admin or by another leader.
membership request (invitation)
An invitation to another individual, whether a registered user or not, to join a Community Platform group or team such as an app team. API Administrators can invite others to be API Administrators; app team members can invite others to the app team. A Site Administrator, Private API Administrator, or Independent Group member can also issue a membership request in the same way.
My APIs
The My APIs quick filter provides a list of APIs that a member who is an API Provider has added. Each API includes functional and usage documentation, and download files.
Navigation: My APIs quick filter
My Apps
The My Apps quick filter is a dashboard that displays all the apps defined by a member. The dashboard is used to manage your app workflow from setup to a live production site.
Navigation: My Apps quick filter
OAuth
OAuth is an open standard security protocol for authorization that allows you to share private resources stored on one site with another site without having to share credentials. One advantage of OAuth is that it supports both authentication and authorization in such a way that an application does not need to give access to the user's credentials. For example, in the platform you can sign in using your Facebook credentials, or on the API Details page you can share an API to Facebook, Twitter, and LinkedIn. These elements of the platform are configured as private resources.
OAuth access token
In OAuth, an access token is essentially a pass, a credential that gives authorization to access the requested and approved resource or resources for as long as the access token remains valid. In some cases, access tokens can be renewed by means of a refresh token; in some cases they cannot. For more information, refer to the OAuth 2.0 specification (external site).
For more information on access tokens, see What is an Access Token?
OAuth authorization code
With the OAuth 2.0 Authorization Code grant type, the resource owner (consumer; for example, the app user) is redirected to the authorization server and gives authorization for the app to access the resource. The authorization server then redirects the consumer back to the client app with an authorization code. The client app presents this authorization code, along with the app's authentication credentials, back to the authorization server, requesting an access token (and optionally a refresh token). The client then uses the access token to call the service on behalf of the resource owner. A refresh token can be used to extend the lifetime of this session.
OAuth authorization endpoint
The endpoint for the OAuth Authorization Server. This is the endpoint on the authorization server where the resource owner provides credentials, such as username and password, in and grants authorization to the client app to access the resources or a specified subset of the resources.
When setting up an OAuth domain, Site Admins must specify this value. Additionally, if an API is using a third-party OAuth provider rather than an OAuth domain set up on the platform, the API Admin must specify this value in OAuth setup wizard. For more information, see What are the OAuth 2.0 Endpoints and how do they work? and the OAuth 2.0 specification (external site).
OAuth authorization server
In an OAuth implementation, the authorization server collects the resource owner's credentials, gets the resource owner's permission for the app to access the resources, and passes back the authorization token to the app so that the app can then access the resources.
OAuth authorization server URL
As part of setting up the OAuth domain, the Site Admin must specify the Authorization Server URL. This is the URL that the browser for the resource owner (app user) will be accessing for the OAuth grant. It is the URL at which the OAuth Provider accesses the requests, for both Authorization Endpoint and Token Endpoint.
As part of setting up an OAuth domain in the platform, the Site Admin must specify the authorization server URL. The URL must be accessible to all the apps and end users that might use APIs that are referencing the OAuth domain. The Authorization Endpoint and Token Endpoint for OAuth 10.a and OAuth 2.0 will use different paths according to the specific OAuth version. Firewalls and DNS servers must be set up for this URL so that end users and apps can access the URL.
OAuth callback URL
Redirect URL. The URL to which the API sends the response message with the token.
OAuth grant types
OAuth 2.0 supports four different grant types; each has a different process flow. Grant types are designated as 2-legged or 3-legged depending on the number of parties involved. The 2-legged grant types are Client Credentials and Resource Owner Password Credentials; the three-legged grant types are Authorization Code and Implicit.
For more information on OAuth grant types (for API admins) see What grant types does OAuth support? and How does OAuth 2-Legged and 3-Legged Authorization work?
OAuth grant types: 2-legged
The number of legs used to describe an OAuth request refers to the number of parties involved; 2-legged or 3-legged. When the client is also the resource owner, it is a 2-legged flow. OAuth 2.0 includes the following 2-legged grant types; Client Credentials and Resource Owner Password Credentials.
OAuth grant types: 3-legged
The number of legs used to describe an OAuth request refers to the number of parties involved. The most common process flow includes three parties; a client, a server, and a resource owner. This is a 3-legged flow. OAuth 2.0 includes the following 3-legged grant types; Authorization Code and Implicit.
OAuth grant types: Authorization Code
A 3-legged OAuth 2.0 grant type: An authorization code is returned to the client through a browser redirect after the resource owner gives consent to the OAuth Authorization Server. The client then exchanges the authorization code for an access token. Resource owner credentials are never exposed to the client app.
OAuth grant types: Client Credentials
A 2-legged OAuth 2.0 grant type: The client presents its own credentials to the OAuth Authorization Server in order to obtain an access token. This access token is either associated with the client's own resources, rather than a specific resource owner, or is associated with a resource owner for whom the client is otherwise authorized to act.
OAuth grant types: Implicit
A 3-legged OAuth 2.0 grant type: An access token is returned to the client through a browser redirect in response to the resource owner authorization request. This grant type is suitable for clients that do not support keeping client credentials confidential (for use in authenticating with the OAuth Authentication Server) such as client applications implemented in a browser using a scripting language like JavaScript.
OAuth grant types: Resource Owner Password Credentials
A 2-legged OAuth 2.0 grant type: The client collects the resource owner's password and exchanges it at the OAuth authorization server for an access token, and often also a refresh token. This grant type is suitable in cases where the resource owner has a trust relationship with the client, such as its computer operation system or a highly privileged application, since the client must discard the password after using it to obtain the access token.
OAuth refresh token
In OAuth 2.0, certain grant types support use of refresh tokens to facilitate longer access periods. This is useful in scenarios that extend over time, such as as a regular monthly payment amount.
In OAuth 1.0a, once an access token is generated it is valid until revoked by the user. OAuth 2.0 introduces expiration of access tokens and adds a second type of token, a refresh token, that can be used in conjunction with the access token to allow users to give long-term permissions but yet maintain security. This process helps ensure that if a specific access token is compromised, a new one can be generated from the refresh token, which can be stored in the database on the server.
The access token grants immediate access but only for a limited time. The access token comes with two additional values: expires_in, which indicates the life of the access token, and refresh_token which can be used to get a new access token when the current token expires. Additional user approval is not needed, but the expiration and renewal add security to the process. When (or before) the access token expires, the refresh token can be used to generate a new access token.
For more information, see What is a Refresh Token?
OAuth resource server
The server where the resources are stored. The resource server accepts requests and responds to approved requests using access tokens.
OAuth token endpoint
In OAuth 2.0, the token endpoint is the endpoint on the authorization server where the client app sends the authorization code, client ID, and client secret and receives in exchange an access token which allows the app to access the approved resources. For more information, see What are the OAuth 2.0 Endpoints and how do they work? and the OAuth 2.0 specification (external site).
OpenID
OpenID is an open standard for authenticating users. It can be used for access control and allows users to log on to different services with the same digital identity where these services trust the authentication body. OpenID simplifies the authentication process because there is only one username and password to remember. For more information, see What is OpenID?
OpenID Connect
An identity layer on top of the OAuth 2.0 protocol which allows the client to verify the identity of an end-user based on authentication by an authorization server. OpenID Connect was released in February 2014 and is gaining popularity. For example, Google is moving from OpenID to OpenID Connect for products such as the Google+ API, used by the platform's Google login domain. For more information, see Welcome to OpenID Connect (external site).
package file
The ZIP file that is created as a result of using the export function. The package file can be imported into another instance of the platform by a Site Admin or API Admin.
PingFederate
A federated identity management system based on the SAML protocol. PingFederate® supports SSO, SLO, and other federated identity standards. It can also be used as an OAuth 2.0 provider.
The platform supports PingFederate provider as a domain type (set up by the Site Admin).
Policy Manager
SOA Software Policy Manager is the core product that provides the underlying infrastructure for the platform. Message handling intermediaries integrate with Policy Manager which attaches policies and provides a policy decision point as well as the policy administration point.
The Policy Manager console is the user interface for the SOA Software API Gateway.
Private API
Private APIs are visible to members who have been invited to join a Private API Group. Once a member has accepted a Private API invitation, the Private API is displayed with a unique icon.
Private API Group
A group associated with a Limited (Private) API and created by an API admin for that API. Each member has a group member role, either as member or leader. Each group can have multiple leaders as well as members.
proxy API
When you set up your API on the Community Platform and choose to use the Proxy feature, all traffic to your API endpoints is channeled via the platform. This offers significant benefits, including the ability to apply policies and monitor traffic at the proxy.
production environment URL
A unique gateway URL (service endpoint) that provides access to the production endpoint of an API. The production endpoint URL becomes available when you request production access, and go live after production access has been approved.
Navigation: My Apps > Apps
profile
In the context of the Community Manager user interface, the user profile page allows you to edit your user details (firstname, lastname, username, and avatar) and settings (email, password, and notifications settings).
Navigation: Profile (to the right of Logout in the top navigation)
Public Key Integration
The Public Key Integration section of My Apps > App Details > Security allows you to use Public Key Infrastructure (PKI) for secure message signing. When you initially create your app, a shared secret is generated by default. If you would like to override the shared secret, you can upload a Certificate Signing Request (CSR). The Certificate Authority associated with the platform will generate a public/private key pair using the uploaded CSR.
Navigation: My Apps > Details > Security
QoS (quality of service) policy
A QoS policy defines the level of service being offered to an app that is accessing an API; for example, the number of transactions per minute that are allowed for the app. In the platform, QoS policies are tied to license terms.
redirection endpoint
In general, a redirection endpoint or URL is a URL that an application provides to another app, when directing the user to the second app to perform some function and then return the user once the function is complete. For example:
  • Login: If the user is logging in with Google, the platform directs the user to Google and provides a redirect URL. When Google has authenticated the user, Google redirects the user back to the platform using the redirect URL.
  • OAuth: if an app is requesting access to one or more of the user's Facebook resources, such as the Calendar, the app directs the user to a Facebook authorization page, and provides a redirect URL. Facebook authenticates the user, collects the user's permission for the app to access the resources, and then uses the redirect URL to return the user to the app.
refresh token
See OAuth refresh token.
relying party
In OpenID Connect, the service provider is called the relying party. The relying party trusts the Connect provider to authenticate the user.
resource
In the Community Platform, a Resource is an item, such as an App or API, which has its own Board and set of activities.
Resource server
See OAuth resource server.
role
Within a Private API Group, each group member has a role, either as Member or Leader. The Private API Admin cam invite team members and designate roles.
Within an independent group, each group member has a role, either as Member, Admin, or Leader. An Admin can invite or remove other team members and designate roles.
Other roles on the platform include App Team Member, Site Administrator, API Administrator, and Site User.
sandbox endpoint URL
A unique gateway URL (service endpoint) that provides access to an APIs sandbox environment. The Sandbox Endpoint URL becomes available after requesting access an API using the Request API Access Wizard.
Navigation: Add APIs in My Apps > API Management, or Request API Access in My Apps.
scope
A subset of a license. A scope is the bridge between the top level of the hierarchy, which is a license, and the bottom level, an operation. At the business level, the Business Admin defines the scope with a name and basic attributes. Then, at the API level, the API Admin assigns specific operations to one or more scopes for the API. These operations are included in any license that the scope is assigned to.
scope mapping
If your API is using the Licenses feature, scope mapping is the key to defining which portions of your API will be available for which licenses. The scopes and licenses themselves are defined by the Business Admin, but at the API level you determine which operations are assigned to which scopes. This in turn determines which licenses will be available to app developers requesting access to your API.
search
The platform includes search functionality on certain specific pages and on platform-wide content. For example, a user can search on the apps list or APIs list for a specific app or API; the Site Admin can search for a specific user in the Users List. Search is available on many other areas of the user interface. Some examples: Board posts, tickets, and alerts; help documentation (question mark at top right; then, Browse Docs).
Search results are limited to those resources the user performing the search has permission to see. For example, a user who does not have access to a specific private API will not see it on the list.
security domain
An application or collection of applications that all share, and trust, common security. The same security mechanism is used for all within the security domain, for authentication, authorization, and/or session management. A user who is authorized on one part of the security domain is considered authorized for other parts.
In a tenant/partner scenario, all tenants share the same security domain and are considered to be trusted. So, for example, app owners on one tenant have access to API information on another tenant seamlessly and without any additional security authorization.
SHA-1
SHA-1 is a cryptographic hash function, broadly used and trusted.
When you hash a value with SHA-1, the hash function returns a 160-bit string. This is the message digest. The value is hashed and sent with the message; at the receipt point, the value is hashed again, and the two hash values are compared. When the two hash values match, it is a secure, reliable indication that the message hasn't changed; the message at the receipt point is an accurate duplication of the message at the send point.
SHA-256
Part of the SHA-2 family of algorithms developed by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) to succeed SHA-1. Each is named according to the number of bits in the output; so, whereas SHA-1 has 160 bits in the hash output, SHA-256 has 256.
Shared Secret
A shared secret is a value generated for an app developer within the secure environment of the platform. The shared secret is known only to the app developer and the platform, and is used for authentication in secure send/receive communications.
Navigation: My Apps > Details > Security
site administrator
An individual who has responsibility for keeping the site running smoothly. The Site Admin has access to additional parts of the user interface for configuration and monitoring purposes. There can be more than one site administrator. For more information, see What functions are available to the Site Administrator in the platform?
SSL
A cryptograpic protocol used to add security to messages by encryption. SSL uses X.509 certificates and asymmetric security. The session key is used to encrypt the messages. SSL offers encryption and identification.
tag
A tag is essentially a keyword or key phrase that's added to a piece of content, or information associated with a resource, to assist in search results. Several different types of resources can have tags assigned to them; for example, apps, APIs, groups, and tickets. Multiple tags are separated by commas.
For example, if an app is a movie general knowledge game, the app owner might assign tags of movie, game, general knowledge; or an API owner can add a category or product line to the metadata for certain APIs so those APIs will come up in search results for that term.
target API
If an API is using the platform as a proxy, the TargetAPI is used to define the destination ("next-hop") endpoint for the API.
target host
When defining a domain in the platform, it is possible to define a virtual host address for each login domain. This is the target host. Example: <role>/<company>.com.
tenant
The tenant is a distinct developer portal and community that is logical separated from any other communities that may be hosted in the same product instance.
The Tenant is managed by the Site Administrator.
ticket
A type of feed entry, representing a trouble ticket created to raise an issue with a resource (app or API) or a connection. Tickets are typically created by a consumer of an API. Any member of the community can comment on a ticket, but it can only be marked as Resolved by the original creator or by an administrator of the target resource. For example, if Joe writes a ticket about an issue with the SkyBlue API, only Joe or the SkyBlue API Admin can mark the ticket as Resolved.
Trusted Certificate Authority
A Trusted Certificate Authority (CA) is a third party identity that is qualified with a specified level of trust. Trusted CA Certificates are used when an identity is being validated as the entity it claims to be. Certificates imported into the Platform Tenant (i.e., Host) must be issued by a Trusted Authority. Trusted CA Certificates must be configured prior to importing X.509 certificates for applications running on the platform.
Navigation: My Apps > Details > Security
unmark
To unmark a discussion, ticket, or other resource means to remove a mark previously placed on the resource. In the user interface, the mark icon is a thumbs-up, and the unmark icon is a closed fist.
version
Each app or API on the platform much have at least one version, and can have multiple versions. When a user creates an app or API on the platform, the first version is created automatically; when using the API it's important to complete both actions. If there is only one app or API version, deleting that version also deletes the app or API.
VIP
Acronym for a virtual IP address.
visibility
A setting that controls the types of users who can see a resource, such as an app, API, group, license, or scope, and any associated items such as discussions and tickets.
There are three possible values. The first two are applicable to all resources that have visibility settings; the third is applicable only to apps, APIs, and groups.
  1. Public: anyone can see the resource, even anonymous users.
  2. Private: the resource is restricted to those who have been specifically invited to have visibility of the resource, usually by joining a private group that has visibility of the resource.
  3. Registered Users: the resource is visible to all users who have logged in, but is not visible to anonymous users.
workflow action
Certain types of activities on the platform must be done in a specific sequence. These are often managed by workflows. Each workflow action changes the state of the resource. Some examples of workflow actions are: requesting or approving an API contract, sending a group membership invitation, or changing the status of a ticket.

Back to top