Valid Values for Components on the Platform

This topic includes lists of valid values for the following common elements used on the platform:

Element Element
API Binding Types MediaType
API Contract State Metric values
API Contract Status Metric Key values
API Pattern Metric Type values
API States Notification Group values
API Types Notification State values
App Security Mechanisms Notification Type values
App Settings OAuth Client Type values
App/App Version State values OpenID Connect Relying Party Response Mode values
App/API Contract Environment (Implementation) values Policy SubTypes
App Version Settings Policy Types
Avatar Providers Published State values
Board Item Types ReportType
BusinessType values ReportType: License Report
Client Authorization Policy Options Reset Status values (for password reset)
CreateMechanism Resource Types
Roles Roles
DescriptionMediaType Search "Type" values
Display Mode Security Challenge Questions
Environment (now called Implementation in the user interface) SignupStatus values
Group Member Roles Sort By values
Group Membership States Sort Order values
Group Settings State (Tenant)
Group States Ticket Label values
Group Types Ticket State values
IdentitySystemType values for domains Ticket Visibility values
IdSystemType values for Login Connector Type Time Intervals
LaaSIntegrationSupport values User Actions on a Resource
Legal Agreement Types User Preferences
Legal Document States User Signup State values
LicenseState values User Status
Login Instruction Types Visibility Settings
Login State Workflow Actions
Login Status Workflow States
  Workflow ObjectTypes

API Binding Types

The binding type indicates whether an API is SOAP or REST. In some cases, a single API could have both binding types.

Valid values for API binding type:

  • REST API: binding.http
  • SOAP 1.1 API: binding.soap11
  • SOAP 1.2 API: binding.soap12

Back to top

API Contract State

During the lifecycle of an API access contract between an app and an API, the contract might have a change in state depending on various events. Certain operations execute workflow actions that result in a change to the state of the API contract. The API access state values are never used in request messages, but are sometimes included in response messages.

For more information about workflow actions relating to API access, refer to App/API Contracts: Valid Workflow Actions.

Note: there are two sets of values relating to contracts—contract state and contract status. Contract state indicates what point in the contract lifecycle the contract is currently in; for example, pending approval, approved, activated. Contract status indicates whether the contract is active, not yet active, or archived, and determines which workflow actions are valid for the contract.

The state values for an API contract are:

  • apicontract.status.pending_approval
  • apicontract.status.config_pending (used only in certain custom workflow scenarios or in LaaS integration)
  • apicontract.status.approved
  • apicontract.status.activated
  • apicontract.status.rejected
  • apicontract.status.resubmitted
  • apicontract.status.suspended
  • apicontract.status.cancelled

Back to top

API Contract Status

The Status value of an API contract is used to determine which workflow actions are valid for the contract at the current time.

Note: there are two sets of values relating to contracts—contract state and contract status. Contract state indicates what point in the contract lifecycle the contract is currently in; for example, pending approval, approved, activated. Contract status indicates whether the contract is active, not yet active, or archived, and determines which workflow actions are valid for the contract.

The status values are shown below.

Value Description
com.soa.apicontract.draft Indicates the contract has not yet been activated. workflow status of Pending Approval, Approved, and any other state before the contract is activated will have this status value.
com.soa.apicontract.inforce Indicates that the contract is either Active or Suspended.
com.soa.apicontract.archived Indicates that the active life of the contract is over. The workflow status of Cancelled, adn any other action that results in the cancellation of the contract (such as deletion of the app or API) will have this status value.

Back to top

API Pattern

The approach used to create a new implementation for an existing API version. Valid values are shown below.

  • com.akana.pattern.proxy
  • com.akana.pattern.target
  • com.akana.pattern.orchestration

Back to top

API States

API states are used by several operations, including GET /api/apis and GET /api/boards/{BoardID}.

State Valid for API Valid for API Version Description
com.soa.api.state.active Yes No The API is active.
com.soa.api.state.deleted Yes Yes The API or API version has been deleted.
com.soa.api.state.open No Yes The API version is active. Corresponds to com.soa.api.state.active for an API.
com.soa.api.state.closed No Yes

The API version has been closed; users cannot request contracts against the API version.

Note: this state is not used by the user interface.

Back to top

API Types

API Types are deprecated. We now use API Binding Types instead. Although the values are shown below, do not use API Types.

Values:

  • REST API: shttp
  • SOAP 1.1 API: soap11
  • SOAP 1.2 API: soap12

Back to top

App Security Mechanisms

An app version can use one or both of the following valid app security mechanisms:

  • com.soa.security.mechanism.sharedsecret
  • com.soa.security.mechanism.pki

Back to top

App Settings

Most app settings used by the AppSettings object, but not all, have two values, one for the enabled state and one for the disabled state. All app setting values are shown below.

Setting Values
PublicAppSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
PublicAppBoardSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
PublicAppRatingsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
PublicAppReviewsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
PrivateAppSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
PrivateAppBoardSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
PrivateAppRatingsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
PrivateAppReviewsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
UserDefinedIdentitySupport
  • com.soa.feature.disabled
  • com.soa.feature.enabled
  • com.soa.feature.enabled.for.siteadmins
SimultaneousSandboxProductAccessSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
ReturnPlainTextSharedSecret
  • com.soa.feature.enabled
  • com.soa.feature.disabled
RegisteredUsersAppSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
RegisteredUsersAppRatingsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
RegisteredUsersAppReviewsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled

Back to top

App/App Version State values

The State setting, com.soa.app.state.xxx, applies to Application and Application Version.

When an app is created it is in Active state, and remains in that state until it is deleted.

There are five possible states for an app version in the Akana API Platform. When a user first creates an app, the first app version is created automatically, and the state is Initial. Other possible values are: Sandbox, Review, Approved, Live. Before any API contracts are initiated, the app version remains in the Initial state.

In setting up the sequence for granting access to an API's Sandbox or Live implementation, the API provider can choose whether a review stage is needed before access to the sandbox implementation is granted, and also whether review is needed before access to the live implementation is granted. As an example, the API owner might decide to grant sandbox access automatically but to require review before approving live (production) access.

The Akana API Platform user interface is designed to guide app developers through these state changes.

Note: Changing an app's state to live gives an application access to the endpoints of all the APIs it has contracts with in the Live implementation. This can only be achieved if all of the app's API contracts are approved in the Live implementation, for all APIs the app has contracts with.

The table below shows all values and whether they apply to app or app version. These are used by many operations and model objects, such as the Application object, in the apps service.

Value Description Applies to App Applies to App Version
com.soa.app.state.active Active Yes --
com.soa.app.state.deleted Deleted Yes Yes
com.soa.app.state.initial Initial state -- Yes
com.soa.app.state.sandbox Sandbox -- Yes
com.soa.app.state.review Review -- Yes
com.soa.app.state.approved Approved -- Yes
com.soa.app.state.live Live -- Yes

Back to top

App/API Contract Environment (Implementation) values

An app can connect to an API in either of two implementations: Sandbox or Live (Production). An app/API contract is always specific to the implementation. Generally, the contract in the Sandbox implementation is first; usually, the Sandbox contract is terminated when the app goes live, activating the contract in the Live (Production) implementation. The user interface uses the value Live; the API in some instances still uses the old value, Production.

In some cases an app can have contracts with the same API Version in both implementations at the same time. Each contract has a unique ContractID.

Note: Earlier versions of the Akana API Platform used the term environment rather than implementation. In occasional instances, you might see API parameters and/or model objects that use the earlier wording.

Back to top

App Version Settings

Most app version settings used by the AppVersionSettings object, but not all, have two values, one for the enabled state and one for the disabled state. All app version setting values are shown below.

Setting Values
AppBoardSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
AppRatingsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
AppReviewsSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
UserDefinedIdentitySupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
  • com.soa.feature.enabled.for.siteadmins
SimultaneousSandboxProductAccessSupport
  • com.soa.feature.enabled
  • com.soa.feature.disabled
ReturnPlainTextSharedSecret
  • com.soa.feature.enabled
  • com.soa.feature.disabled

Back to top

Avatar Providers

Valid values for AvatarProvider are as follows:

  • com.soa.imageprovider.type.gravatar
  • com.soa.imageprovider.type.default (platform default avatar)

Back to top

Board Item Types

BoardItemType can be any of the below.

Note: Although the user interface renders the names of Board item types in all caps, all operations should use the values exactly as shown below.

Value Description Can Artifacts Be Attached (if allowed)?
Discussion A discussion about an app or API. Yes
Ticket A ticket relating to an app or API. Yes
ContractRequest A request for a contract between an app and an API. No
GroupMemberReq A group member invitation. No
Alert An alert relating to an app or API. Yes
Review A review of an app or API. Yes

Back to top

BusinessType values

Valid values for BusinessType are as follows:

  • Company
  • Department
  • Project
  • Application
  • Partner

The default is Company.

Back to top

Client Authorization Policy Options

Value Description
com.soa.oauth.client.public Public Client. Client does not provide shared secret or PKI; verification is based only on the redirect URL. All OAuth grant types are supported. When using our provider, the app visibility must be set to Public.
com.soa.oauth.client.security.basicauth Confidential Client. Client provides client_id and client_secret in basic authentication header.
com.soa.oauth.client.security.https.2way Confidential Client. Client uses two-way HTTPS to invoke the OAuth 2.0 Token Endpoint. Client is verified using the client certificate from the HTTPS socket.
com.soa.oauth.client.security.client.id_security Confidential Client. Client uses client_id and client_secret as HTTP GET/POST parameters, as outlined in the OAuth 2.0 specification.

Back to top

CreateMechanism values

CreateMechanism indicates the implementation pattern used to create an API. Valid values are as follows:

  • CLONE
  • PROXY
  • EXISTING_ASSET
  • PHYSICAL_SERVICE

Back to top

Console Resource dynamic variable values

In the Console Resource API, in the GET /resources/{path:.*} operation, dynamic parameter, you can use the following variables:

  • ${scripts.version}
  • ${resource.version}
  • ${theme.name}
  • ${tenant.id}
  • ${context.path}
  • ${cdn.root}
  • ${document.domain}
  • ${analytics.accountid}
  • ${tenant.name} (the display name for the tenant)

Back to top

DescriptionMediaType

Valid values for DescriptionMediaType are as follows:

  • text/plain
  • text/markdown

DescriptionMediaType provides information about the media type for the content of a board item (forum entry). This is applicable to the following board item types: discussion, ticket, alert, or review.

Back to top

Display Mode

Valid values for display mode are as follows:

  • MAINPAGE
  • POPUP

For example, these values are part of the LoginDomain object used by the GET /api/users/{UserID}/logindomain operation.

Back to top

Environment (now called Implementation in the user interface)

Valid values for environment (now called implementation in the user interface) are as follows:

  • Sandbox
  • Production

Note: The user interface now uses the values Sandbox/Live rather than Sandbox/Production. You might see either value in the API, Live or Production. In most cases, the old value, Production, is still used.

Back to top

Group Member Roles

Group member roles and their values are listed below.

Value Description
com.soa.group.membership.role.admin Administrator
com.soa.group.membership.role.leader Leader
com.soa.group.membership.role.member Member

Back to top

Group Membership States

The following states are valid for group membership:

Value Description
com.soa.group.membership.state.pending Pending
com.soa.group.membership.state.approved Approved
com.soa.group.membership.state.disapproved Declined
com.soa.group.membership.state.cancelled Cancelled
com.soa.group.membership.state.removed Removed
com.soa.group.membership.state.group.deleted Deleted

Back to top

Group Settings

Valid values for group settings are shown below.

Group Settings: GroupBoardSupport

The GroupBoardSupport property indicates whether a Board is supported for the group.

Possible values:

  • Enabled: com.soa.feature.enabled
  • Disabled: com.soa.feature.disabled

For example, this property is part of the Group Settings object returned by the GET /api/groups/{GroupID} operation

Group Settings: GroupRatingsSupport

The GroupRatingsSupport property indicates whether ratings are supported for the group.

Possible values:

  • Enabled: com.soa.feature.enabled
  • Disabled: com.soa.feature.disabled

For example, this property is part of the Group Settings object returned by the GET /api/groups/{GroupID} operation

Group Settings: GroupReviewsSupport

The GroupReviewsSupport property indicates whether reviews are supported for the group.

Possible values:

  • Enabled: com.soa.feature.enabled
  • Disabled: com.soa.feature.disabled

For example, this property is part of the Group Settings object returned by the GET /api/groups/{GroupID} operation

Back to top

Group States

There are two valid states for a group, as shown below.

Value Description
com.soa.group.state.active Active
com.soa.group.state.deleted Deleted

Back to top

Group Types

In practical terms, the only valid group type you'll see in working with the Akana API Platform API is for an independent group:

  • com.soa.group.type.independent

Usage example: Group Type is part of the Group object.

Additional group type values are used by the API in some contexts, but these are reserved. The value above is the only one in general use. The additional group types are for app teams, API administrators, site administrators, and business administrators.

Back to top

IdentitySystemType values for domains

Each type of domain on the platform has a unique IdentitySystemType. The values below are supported.

This Value... Is used for this type of domain...
com.akana.securitydomain.external.oauth.provider External OAuth Provider domain
com.soa.securitydomain.fb.connector Facebook Connector domain
com.soa.securitydomain.google.connector Google Connector domain
com.soa.securitydomain.oauth.provider OAuth Provider domain
com.soa.securitydomain.openid.relyingparty OpenID Connect Relying Party domain
com.soa.securitydomain.pingfederate.provider PingFederate Provider domain

Back to top

IdSystemType values for Login Connector Type

Each login domain connector type has a unique IdSystemType value. The login domain connector types that are available for a specific instance of the platform depend on the nature of the platform instance, including installation and configuration choices and any customization.

Some of the standard IdSystemType values are shown below. For additional connector types, refer to the documentation from the connector providor.

You can check the IdSystemType values for your installation by running the GET /api/login/domains operation.

This Value... Is used for this type of login connector...
com.soa.securitydomain.openid.relyingparty Google login
com.soa.securitydomain.fb.connector Facebook login
Directory Server LDAP/Active Directory login
Policy Manager Platform login

Back to top

LaaSIntegrationSupport values

Indicates the status of the Lifecycle Manager integration feature. Possible values:

  • Enabled: com.soa.feature.enabled
  • Disabled: com.soa.feature.disabled

Back to top

Legal Agreement Types

The platform allows you to specify a type for your legal agreement documents. The only reserved legal agreement type is the signup agreement, as listed below.

Value Description
com.soa.atmosphere.legals.eula End-user license agreement (used by the platform user interface)
com.soa.atmosphere.legals.signup Signup agreement

Back to top

Legal Document States

The State or DocumentState value of a legal document indicates its activation state. When the document is first added, it is in a draft state. Once the document has been activated, the API Admin can switch states between active and inactive.

Possible values:

  • Draft: com.soa.status.draft
  • Active: com.soa.status.active
  • Inactive: com.soa.status.inactive

Back to top

License State values

A license can be in either of the following states:

  • Active
  • InActive

Back to top

Login Instruction Types

Login instruction types (instructionType in the response message) are used by the login service. The GET /api/login/ssoLoginInstructions operation first determines the next step needed to log the user in, depending on the login option the user has selected, and then it returns a value for the login instruction type, as well as additional values. For example, if the login instruction type is NeedCredentials, the response also indicates which credentials to collect; if the instruction type is NeedRedirect, the response includes the redirect URL.

Value Description
NeedCredentials Login credentials are needed. Used for some LDAP logins. The specific credentials required are defined as part of the response. For example, login credentials might be Username and Password or SSN and PIN.
NeedRedirect User must be redirected to another URL for validation. Used for identity providers such as Google and Facebook. The specific redirect URL is specified as part of the response. For example, login with Google redirects the user to a Google login screen (unless the user is already logged in).
Complete Login is complete; nothing else is needed. Used in scenarios where an SSO provider uses a cookie as an SSO token; for example, SiteMinder.

Back to top

Login State

The login operation returns the user's login state (loginState field) indicating where in the login process the user currently is. If there are tasks that must be completed for the user to be fully logged in, those are indicated by the value of the loginState field, and specified in the pendingTasks field. For example, the user might need to change the password, provide answers to security challenge questions, or accept the platform legal agreement. Valid values are shown below.

Value Description
login.complete Login is fully complete with no pending tasks.
login.inprocess Indicates that the user must complete one or more tasks before login is complete. Tasks are listed in the pendingTasks field of the LoginResponse object.

Back to top

Login Status

The login status, returned in the response to the GET /api/login/ssoLogin operation, indicates the user's status in terms of login. There are three possible values:

  • Active
  • In-Active
  • Disabled

Back to top

Media Type values

Valid values for MediaType are as follows:

  • text/plain
  • text/markdown

MediaType provides information about the media type for a comment associated with a discussion, ticket, alert, or review.

Back to top

Metric values

Metric values are used in reporting API platform usage for a specific tenant.

There are two sets of values, as shown below.

Metric values: Values relating to supported identity systems:
  • AppCount
  • ApiCount
  • UserAccountsCount
  • PlatformApiUsage
  • CustomerApiUsage
  • PortalVanityURLUsage
  • ApiVanityURLUsage
  • DeploymentZonesUsage
  • IdentitySystem-OAuthProviderCount
  • IdentitySystem-OpenIDConnectRelyingPartyCount
  • IdentitySystem-ExternalOAuthProviderCount
  • IdentitySystem-PingFederateProviderCount
  • IdentitySystem-GoogleProviderCount
  • IdentitySystem-FacebookProviderCount
  • IdentitySystem-LDAPProviderCount
  • IdentitySystem-SiteMinderProviderCount
  • IdentitySystem-SAMLWebSSOProviderCount

Back to top

Metric Key values

The metric key indicates the information type. It corresponds to the column name in the metrics export file, if the information is exported.

Possible values:

  • avgResponseTime
  • minResponseTime
  • maxResponseTime
  • totalCount
  • successCount
  • faultCount

Back to top

Metric Type values

The metric type indicates additional information about how the metric is aggregated.

Possible values:

  • Aggregate: the metric information includes only aggregate metric values.
  • PerDayWithAggregate: The metric information includes per day usage as well as aggregate usage, if that information is available.

Back to top

Notification Group values

As part of their preference settings, users can choose whether to receive email notifications for events in the categories listed below. Notifications are sent by default. These settings are returned by the GET /api/users/{UserID}/settings operation, and can be modified using the PUT /api/users/{UserID}/settings operation.

Valid notification groups are listed in the table below.

This notification group... Sends notifications when...
com.soa.notification.type.app.alert The user's app receives an alert.
com.soa.notification.type.app.lifecycle There is a major lifecycle change for the user's app.
com.soa.notification.type.app.post A post is created for the user's app.
com.soa.notification.type.appteam There is a change to the app's team.
com.soa.notification.type.contract.state.change There is an API access change for the user's app.
com.soa.notification.type.news.update There is a platform news update.
com.soa.notification.type.post.comment Someone comments on one of the user's posts.
com.soa.notification.type.privateapi There are changes to the user's API Scope Group.
com.soa.notification.type.ticket.change Tickets referencing the user's app are created or updated.

Back to top

Notification State values

When a user first receives a notification, the notification state is Unread. Other valid notification states are: Read, Archived.

Back to top

Notification Type values

Valid values for NotificationType are as follows:

  • com.soa.notification.type.ticket.change
  • com.soa.notification.type.privateapi
  • com.soa.notification.type.post.comment
  • com.soa.notification.type.news.update
  • com.soa.notification.type.contract.state.change
  • com.soa.notification.type.appteam
  • com.soa.notification.type.app.post
  • com.soa.notification.type.app.lifecycle
  • com.soa.notification.type.app.alert
  • com.soa.notification.type.api.auto.connect

Note: To return a list of notification types, you can run the GET /api/notifications/types operation.

Back to top

OAuth Client Type values

Valid values for OAuth Client Type are as follows:

  • Confidential: com.soa.oauth.ctype.confidential
  • Public: com.soa.oauth.clienttype.public

Back to top

OpenID Connect Relying Party Response Mode values

The response_mode value in the request determines the type of response that will be returned. Supported values for the platform's OpenID Connect Relying Party domain response mode (response_mode parameter) are as follows:

  • form_post
  • query
  • fragment

Back to top

Policy SubTypes

As part of API setup, the API owner or administrator can define one or more policies that govern the API's operation. Policies are categorized into policy types and policy subtypes. Policy subtypes are listed below.

Value Description
policy.apisec API security policy
policy.auditservice auditing policy
policy.cors CORS policy
policy.oauth OAuth policy

For an example of how policy subtype values are used, see the GET /api/policies operation.

Back to top

Policy Types

As part of API setup, the API owner or administrator can define one or more policies that govern the API's operation. Policies are categorized into the policy types listed below.

Note that URL encoding of spaces (%20) is needed if these values are used in a request parameter.

Value Description
Denial of Service A policy that defines conditions for protecting against, and/or dealing with, a Denial of Service attack.
Service Level Policy A specific type of Quality of Service (QoS) policy that defines conditions for measuring and reporting performance for a specific contract.
Operational Policy A policy that defines requirements for addressing the operational implications of services that are shared across enterprise departments. These policies address the operational model for services, capacity monitoring and planning, the handling of policy exceptions and violations, and service execution including the definition and enforcement of runtime policies such as security, access, logging procedures, and service reliability.
Compliance Policy A policy that allows an organization to create standards that control the quality of the data in the repository. These policies can be used to analyze the service metamodel, WSDL documents, Schema, and transactional data to determine whether they meet corporate standards.

For an example of how policy type values are used, see the GET /api/policies operation.

Back to top

Published State values

Valid values for the published state for a piece of user-generated content, such as a discussion, ticket, alert, review, or comment, are:

  • Unpublished
  • Published

Back to top

ReportType

Valid values for the ReportType parameter are shown in the table below.

This parameter is used by the following metrics operations Apps and APIs services:

The second column indicates where these operations are currently used in the platform user interface.

Value Usage in Platform UI / Output Info
api.all.apps

App monitoring tab: Overview, middle row left side pie chart

Output columns: appName, Count

service.all.operations

API monitoring tab: Overview, Usage By Operation

Output columns: Operation, Count

business.top10.apis

API and App monitoring tab: Overview, bottom row – top APIs chart

Output columns: ApiName (version), Count

app.all.apis

App monitoring tab: Overview, API usage.

Output columns: apiName, Count

Back to top

ReportType: License Report

Valid values for the ReportType parameter (in the user interface, used in the License Report) are shown in the tables below.

The license report for APIs (see GET /api/apis/versions/{APIVersionID}/licensereport) references the following ReportType values.

Value Meaning
api.usage.app.quotas Only available if an SLA policy is assigned to the contract, this reports the quote assigned to the contract and the actual consumption level over the designated time period. For example, if 1000 transactions per hour are allowed, the user interface shows a line for the 1000 transactions and a bar showing the actual usage. The values are used to build the chart.
api.usage.by.license This reports the API usage distribution per license. An example scenario might be if an API is offered to some apps for a fee and some for a cost. The free license consumption might be 70% of the API traffic, and the paid API calls consuming the remaining 30%. In the user interface, this information is depicted in a pie chart. The report value sends the data needed to draw the chart.
api.usage.by.app.per.license This reports the API consumption per app, per license.

The license report for apps (see GET /api/apps/versions/{AppVersionID}/licensereport) references the following ReportType value.

Value Meaning
app.usage.api.quotas Only available if an SLA policy is assigned to the contract, this reports the quote assigned to the contract and the actual consumption level over the designated time period. For example, if 1000 transactions per hour are allowed, the user interface shows a line for the 1000 transactions and a bar showing the actual usage. The values are used to build the chart.

Back to top

Reset Status Values (for password reset)

When a user is resetting the password, and security challenge questions are in effect, the API tracks whether the user's answer to the security question was valid. If there are three incorrect answers, the user is locked out for 30 minutes. Reset status values, returned in the response are shown below.

These are returned in the response for the POST /api/login/authenticateWithPasswordResetCode (authenticate with password reset code) operation.

  • user.password.reset.valid.answer
  • user.password.reset.invalid.challenge
  • user.password.reset.invalid.answer

Back to top

Resource Types

The Users service includes operations that report on a specific user's connection with a resource type.

For the purposes of these operations, valid values for resource type are as follows:

  • app
  • app-version
  • api
  • apiversion
  • group

Back to top

Roles

The different authorization roles determine which user groups can perform actions on specific types of resources.

For detailed information on authorization roles, see the separate reference article, Authorization Roles on the Platform.

Back to top

Search "Type" Values

When using the Search operation (GET search), you can define a search type in the q field. Valid values for search type are shown below. For an example of how this is used, see Using Search on the Platform (example #4).

  • app
  • app-version
  • api
  • apiversion
  • alert
  • comment
  • discussion
  • group
  • review
  • ticket
  • user
  • doc

Back to top

Security Challenge Questions

Depending on the platform's settings, one or more security challenge questions might be required as a security measure. On signup, the user chooses out of the questions offered, and provides answers which are stored securely in the database. The security challenge questions provide an added measure of security for certain operations relating to the user account, such as password reset, profile changes, and password change.

The platform has certain default security questions; new questions can be added by the Business Admin. The default questions are shown below.

Code Text Value
com.soa.challenge.question.pet What is the name of your pet?
com.soa.challenge.question.city.birth What is the city of your birth?
com.soa.challenge.question.color What is your favorite color?
com.soa.challenge.question.mothers.name What is your mother's maiden name?

Back to top

SignupStatus values

SignupStatus indicates a platform user's status with regard to signing up for the platform. Possible values:

  • user.signup.confirm.email
  • user.signup.complete
  • user.signup.email.next.steps

Back to top

Sort By values

As part of retrieving some types of information, such as the Board for an app or API, you can define a sort value for the information that's returned. Valid values are shown below.

This sort by... Has this value... Which indicates this Selection...
SORT_BY_UPDATED com.soa.sort.order.updated Most recently updated items are first.
SORT_BY_RELEVANCE com.soa.sort.order.relevance Items with the highest relevance are first.
SORT_BY_ALPHABETICAL com.soa.sort.order.alphabetical Sort alphabetically (A to Z, with A at the top).
SORT_BY_RATING com.soa.sort.order.rating Sort with the highest ratings at the top.
SORT_BY_CONNECTIONS com.soa.sort.order.connections Items with the most connections are first.
SORT_BY_FOLLOWERS com.soa.sort.order.followers Items with the most followers are first.

For an example of how sort order is used, see the GET /api/policies operation.

Back to top

Sort Order values

As part of retrieving some types of information, such as the Board for an app or API, you can define the sort order for the information that's returned. Valid values are shown below.

This sort order... Has this value... Which indicates this selection...
SORT_ASCENDING asc Sort in ascending order
SORT_DESCENDING desc Sort in descending order

For an example of how sort order is used, see the GET /api/policies operation.

Back to top

State (Tenant)

Valid state value for a tenant are:

  • com.akana.tenant.state.active
  • com.akana.tenant.state.suspended

Back to top

Ticket Label values

The platform supports the writing and tracking of tickets on apps and APIs. Authorized users can assign a label to the ticket indicating its priority. The same user, or another authorized user, can change the priority value of a ticket.

This Ticket Label... Indicates this Priority... And has this value in the User Interface...
com.soa.ticket.label.priority.low Low priority Minor
com.soa.ticket.label.priority.medium Medium priority Major
com.soa.ticket.label.priority.high High priority Critical

Back to top

Ticket State values

The platform supports the writing and tracking of tickets on apps and APIs. When it's first opened, the ticket is in a state of OPEN. Typically, the process includes a transition to the states of ACTIVE, RESOLVED, and CLOSED. In some cases the process might be a little different.

The current state of a ticket determines the state changes that are valid. For example, a ticket must be closed before it can be reopened; it must be active before it can be resolved.

The ticket state indicates where the ticket currently stands in the process. Valid values are shown below.

This Ticket State... Has this Value... Which indicates...
TICKET_STATE_CLOSED CLOSED The ticket has been closed.
TICKET_STATE_REOPEN REOPEN The ticket has been reopened.
TICKET_STATE_OPEN OPEN The ticket is currently open, and has never been closed.
TICKET_STATE_RESOLVE RESOLVED The ticket has been marked as resolved, but not yet closed.
TICKET_STATE_ACTIVE ACTIVE The ticket is currently active.

Back to top

Ticket Visibility values

The ticket visibility setting determines who can see unpublished tickets. Valid choices:

  • com.soa.visibility.apivisibility: Visible to anyone who has visibility of the associated API.
  • com.soa.visibility.limited: Visible to the submitter, API Admins, and app team members only if the ticket was submitted in the context of a specific API.

In the developer portal, ticket visibility is specified by the Site Admin: Admin > Settings > Tickets.

Back to top

Time Intervals

By default, the platform supports tracking of metrics in the increments shown below.

This designation... Indicates this unit of measure... And is available in these increments...
s Seconds Five-second increments (5s)
m Minutes Fifteen-minute increments (15m)
h Hours Hourly increments (1h, 2h, etc.) up to 24h
d Days Daily increments (1d, 2d etc.)
w Weeks Weekly increments (1w, 2w, etc.)
M Months Monthly increments (1M, 2M, etc.)

for more information about time intervals, refer to Working with Time Zones and Time Intervals.

Back to top

User Actions on a Resource

Valid actions users can take on a resource, such as an app or API, are as follows:

  • Add
  • Modify
  • Delete
  • Read
  • Monitor

For example, these values are used in one of the query parameters for the GET {UserID}/auzstatus operation.

Back to top

User Preferences

As part of their preference settings, users can choose to dismiss certain parts of the platform help content that are designed for helping new users set started. In the user interface, the user clicks to close the dismissible help panel. Using the API, user preferences are set with the POST /api/users/{UserID}/preferences operation.

Valid user preferences are listed in the table below. Valid values for user preferences are open, which displays the help, or closed, which dismisses the help.

To Dismiss the help content for this page... Specify This user preference...
Edit Profile page com.soa.helptext.edit.profile.helpClosed
Dashboard com.soa.helptext.dashboard.helpClosed
Create Group com.soa.helptext.create.group.helpClosed
Group Access com.soa.helptext.group.access.helpClosed
App Home (Open) com.soa.helptext.app.home.helpClosed
My Apps (some tenants only) com.soa.helptext.myapps.home.helpClosed

Back to top

User Signup State values

The user signup state can be either of the following:

  • pending_validation
  • registered

Back to top

User Status

A user with Site Admin rights can enable or disable an existing user. A user who has been disabled no longer has access to the platform. After disabling a user's access, the Site Admin can enable it, which restores any access rights the user previously had.

Similarly, the Site Admin can lock a user's account, or can unlock it if it was locked either by the Site Admin or because of failed password attempts.

Valid values for UserStatus are as follows:

  • com.soa.user.status.disabled
  • com.soa.user.status.enabled
  • com.soa.user.status.locked
  • com.soa.user.status.unlocked

For example, these values are used by the PUT /api/users/{UserID}/status operation.

Back to top

Visibility Settings

Visibility options vary according to the resource type. For details, see below.

Visibility for app, APIs, or groups

Apps, APIs, and groups have a Visibility setting that controls what type of users have read access to the resource. Examples of operations that use the Visibility setting are:

For app, API, or group visibility, there are three valid values:

  • Public: everyone can see the resource.
  • Limited:
    • App: An app is visible only to app team members
    • API: An API is visible only to API Administrators or API Scope Group members
    • Group: Groups are visible to those who have group membership
  • com.soa.visibility.registered.users: platform users who are logged in.

Visibility for Alerts, Discussions, Reviews, and Tickets

Alerts, Discussions, Reviews, and Tickets are governed by the same three visibility values as above for apps, APIs, or groups. For example:

  • A discussion for a specific group is visible to all who have visibility of the group.
  • A ticket on a specific API is visible to those who have visibility of the API: API Admins, app team members for any apps that are associated with the API, and members of any groups that have visibility of the API or of an associated app.

Note: The information above is for published Board items. When Board items are moderated, visibility is also affected by the item's publication status. For more information, see Boards in the Portal: Forum Moderation.

Visibility for Comments

A published comment on a Board item, such as a discussion or ticket, is visible to those who have visibility of the Board item itself. However, note that visibility is also affected by the comment's publication status. If the comment is unpublished, it has reduced visibility. For more information, see Boards in the Portal: Forum Moderation.

Visibility for Licenses and Scopes

For licenses and scopes, there are two valid values:

  • Public: anyone who is authorized to see an API can see public licenses or scopes associated with the API.
  • Limited: users must be authorized to see the API and, additionally, specifically invited to have visibility to the private licenses or scopes. Uninvited users see other parts of the API, including public licenses, but do not see the private licenses or scopes.

For general information on how privacy works with the License feature, refer to the developer portal user interface help (Licenses).

Visibility for users

For users, visibility is always Public.

Note: If an app has multiple versions, the visibility setting for the app is Private if at least one version is set to Private.

For more information about visibility of apps, see Public and Limited (Private) Apps.

Back to top

Workflow Actions

Valid workflow actions for various types of resources are shown in the tables below.

For more information about workflow actions, including process flow diagrams, see Executing Workflow Actions.

All Groups: Valid Workflow Actions

Action Value
Accept (must be an invited group member who has not yet accepted or declined) group.membership.action.accept
Decline (must be an invited group member who has not yet accepted or declined) group.membership.action.decline
Resend (must be a group administrator resending to an invited group member who has not yet accepted or declined) group.membership.action.resend
Remove (must be a group administrator removing a current group member) group.membership.action.remove

API Scope Groups and Independent Groups: Additional Workflow Actions

Action Value
Make Admin (must be a Member or Leader) group.membership.action.make.admin
Make Leader (must be a Member or Admin) group.membership.action.make.leader
Make Member (must be an Admin or Leader) group.membership.action.make.member

Tickets: Valid Workflow Actions

To perform any of the actions listed below, the user must be an app team member, author or submitter of the ticket, or API or Business Administrator. The Site Administrator can delete an action.

Action Value
Resolve ticket.action.resolve
Close (must be open) ticket.action.close
Reopen (must be closed) ticket.action.reopen
Delete ticket.action.delete
Edit priority (doesn't change the state of the ticket) ticket.action.edit.priority

App/API Contracts: Valid Workflow Actions

The Contracts workflow actions switch an app/API contract from one valid state to another. Again, the two conditions to be met are 1) the requestor is authorized to make the change, and 2) the change is valid for the specific contract. In order for the switch to be valid, the old state must be the current state of the object, and the new state must be a valid change.

Description Value
Approve apicontract.action.approve
Activate apicontract.action.activate
Cancel apicontract.action.cancel
Reject apicontract.action.reject
Resubmit apicontract.action.resubmit
Suspend apicontract.action.suspend
Resume apicontract.action.resume

Discussions: Valid Workflow Actions

The Discussions workflow actions govern how discussions are managed on the platform.

Description Value
Approve discussion.action.approve.publish
Delete discussion.action.delete
Reject discussion.action.reject.publish
Resubmit discussion.action.resubmit
Unpublish discussion.action.unpublish

Reviews: Valid Workflow Actions

The Reviews workflow actions govern how reviews are managed on the platform.

Description Value
Approve review.action.approve.publish
Delete review.action.delete
Reject review.action.reject.publish
Resubmit review.action.resubmit
Unpublish review.action.unpublish

Comments: Valid Workflow Actions

The Comments workflow actions govern how comments are managed on the platform.

Description Value
Approve comment.action.approve.publish
Delete comment.action.delete
Reject comment.action.reject.publish

Back to top

Workflow States

The workflow state values depend on the workflow definition XML file. For details of workflow states for your specific installation, refer to the applicable XML file.

In the user interface you can find the XML file. First check which workflow file is in use, in the applicable Administration / Config page (APIs, Apps, Tickets, and so forth). Then, go to Administration/Workflows and view or download the file.

Back to top

Workflow ObjectTypes

For workflows, ObjectType is a type of resource to which a custom workflow can be applied. Valid values are:

  • oauth-grant
  • apicontract
  • grpmbrship
  • ticket
  • user
  • app-version
  • review
  • comment
  • discussion

Back to top

Related Topics