Valid Values for Components on the Platform
This topic includes lists of valid values for the following common elements used on the platform:
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
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
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. |
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
API States/API Version 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.draft | Yes | Used in custom API version workflow. See POST /api/apis/versions/{ApiVersionID}/action. | |
| com.soa.api.state.pending_approval | Yes | Used in custom API version workflow. See POST /api/apis/versions/{ApiVersionID}/action. | |
| com.soa.api.state.rejected | Yes | Used in custom API version workflow. See POST /api/apis/versions/{ApiVersionID}/action. | |
| com.soa.api.state.active | Yes | Yes | 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: Tthis state is not used by the user interface. |
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
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
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 |
|
| PublicAppBoardSupport |
|
| PublicAppRatingsSupport |
|
| PublicAppReviewsSupport |
|
| PrivateAppSupport |
|
| PrivateAppBoardSupport |
|
| PrivateAppRatingsSupport |
|
| PrivateAppReviewsSupport |
|
| UserDefinedIdentitySupport |
|
| SimultaneousSandboxProductAccessSupport |
|
| ReturnPlainTextSharedSecret |
|
| RegisteredUsersAppSupport |
|
| RegisteredUsersAppRatingsSupport |
|
| RegisteredUsersAppReviewsSupport |
|
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 |
App/API Contract Environment (Implementation) values
An app can connect to an API in either of two implementations: Sandbox or 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.
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 |
|
| AppRatingsSupport |
|
| AppReviewsSupport |
|
| UserDefinedIdentitySupport |
|
| SimultaneousSandboxProductAccessSupport |
|
| ReturnPlainTextSharedSecret |
|
Avatar Providers
Valid values for AvatarProvider are as follows:
- com.soa.imageprovider.type.gravatar
- com.soa.imageprovider.type.default (platform default avatar)
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 |
BusinessType values
Valid values for BusinessType are as follows:
- Company
- Department
- Project
- Application
- Partner
The default is Company.
Client Authorization Policy Options
CreateMechanism values
CreateMechanism indicates the implementation pattern used to create an API. Valid values are as follows:
- CLONE
- ORCHESTRATION
- PHYSICAL_SERVICE
- PROXY
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)
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.
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.
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 or Production. In most cases, the old value, Production, is still used.
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 |
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 |
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
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 |
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.
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 (deprecated in version: 2020.1.0) |
| 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 |
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 |
LaaSIntegrationSupport values
Indicates the status of the Lifecycle Manager integration feature. Possible values:
- Enabled: com.soa.feature.enabled
- Disabled: com.soa.feature.disabled
Legal Agreement Supported File Types
The following file formats are supported for legal agreements on the platform:
- Text (.txt, .text)
- HTML (.htm, .html)
- PDF (.pdf)
Note: Supported file formats are the same for these two types of legal agreements supported on the platform:
- Platform signup legal agreement: If a platform signup legal agreement is in place, all platform users much accept the agreement.
- API legal agreement: Specific to an API. Must be accepted as part of requesting access to an API.
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 |
Legal Document States
The State or DocumentState value of a legal document uploaded to the Community Manager developer portal indicates its activation state
DocumentState, which indicates the current status of a legal document uploaded to the Community Manager developer portal, is used by two services:
- Legals service, which allows upload and management of the platform developer agreement.
- APIs service, which allows upload and management of a legal agreement for an individual API.
Possible values:
| Value | Description |
|---|---|
| Draft: com.soa.status.draft | Used by APIs service only. 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. |
| Active: com.soa.status.active |
Used by both services. Indicates that the legal document is in effect and must be accepted before using the platform, for the developer legal agreement, or before using the API, for an API legal agreement. For a platform legal agreement, the default value, if the legal document state is not specified, is Active. |
| Inactive: com.soa.status.inactive | Used by both services. Indicates that the legal agrement has been uploaded to the Community Manager developer portal but is not active; users do not have to accept the legal agreement and do not even see it. |
License State values
A license can be in either of the following states:
- Active
- InActive
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. |
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. |
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
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.
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: |
|---|---|
|
|
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.
Metric key values are used by several operations that reference the Graph Object, used in app and API analytics.
Possible values:
- avgResponseTime
- minResponseTime
- maxResponseTime
- totalCount
- successCount
- faultCount
- totalRequestSize (valid in version: 2019.1.14 and later)
- totalResponseSize (valid in version: 2019.1.14 and later)
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.
Model State values
The state values for a model object are:
- com.akana.model.state.draft
- com.akana.model.state.pending_approval
- com.akana.model.state.rejected
- com.akana.model.state.active
- com.akana.model.state.deleted
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. |
Notification State values
When a user first receives a notification, the notification state is Unread. Other valid notification states are: Read, Archived.
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.
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
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
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.
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.
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
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:
- App / Get Metrics: GET /api/apps/versions/{AppVersionID}/metrics
- App / Export Metrics: GET /api/apps/versions/{AppVersionID}/metrics/export
- API / Get Metrics: GET /api/apis/versions/{APIVersionID}/metrics
- API / Export Metrics: GET /api/apis/versions/{APIVersionID}/metrics/export
- Business / Get Metrics: GET /api/businesses/{BusinessID}/metrics
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 |
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. |
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
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
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.
Search "Type" Values
When using the Search operation (GET /api/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
For a search type of doc, all Community Manager developer portal content files (ending in .htm or .html) are searched. All words in the content files are included in the search index, except words that have been defined as stop words (generally small and simple words such as the, to, at, as).
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? |
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
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.
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.
State (Tenant)
Valid state value for a tenant are:
- com.akana.tenant.state.active
- com.akana.tenant.state.suspended
Status (HTTP)
One more more specific HTTP status values. If Status is specified, only transactions with that status are included in the results. To specify multiple statuses, include multiple Status query parms, one for each status.
Valid Status values:
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 |
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. |
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 Community Manager developer portal, ticket visibility is specified by the Site Admin: Admin > Settings > Tickets.
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.
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.
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 |
User Signup State values
The user signup state can be either of the following:
- pending_validation
- registered
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.
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:
- PUT /api/apis/versions/{ApiVersionID}/info (in request and response)
- POST /api/groups (in request and response)
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 Community Manager 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.
Workflow Actions
Valid workflow actions for various types of resources are shown in the tables below. They include:
- All Groups: Valid Workflow Actions
- API Scope Groups and Independent Groups: Additional Workflow Actions
- Tickets: Valid Workflow Actions
- API Versions: Valid Workflow Actions
- App Versions: Valid Workflow Actions
- App/API Contracts: Valid Workflow Actions
- Discussions: Valid Workflow Actions
- Reviews: Valid Workflow Actions
- Comments: Valid Workflow Actions
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 a ticket.
| 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 |
API Versions: Valid Workflow Actions
The API version workflow is optional. If custom workflow is implemented, these workflow actions govern how API versions are managed on the platform.
As always with workflow, the user performing the workflow action must be authorized to perform the action, and the action must be valid for the object's current state.
| Description | Value |
|---|---|
| Submit for Approval | apiversion.action.submit.approval |
| Approve | apiversion.action.approve |
| Reject | apiversion.action.reject |
| Resubmit | apiversion.action.resubmit |
App Versions: Valid Workflow Actions
App version workflow is optional. If a custom workflow is implemented, these workflow actions govern how app versions are managed on the platform.
The workflow actions that are valid are determined by the custom workflow itself.
As always with workflow, the user performing the workflow action must be authorized to perform the action, and the action must be valid for the object's current state.
To check the valid workflow actions for the current user, use the GET /api/workflow/objects/{ObjectID}/actions operation.
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 |
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 / Settings page (APIs, Apps, Tickets, and so forth). Then, go to Administration/Workflows and view or download the file.
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
- model
- ticket
- user
- app-version
- review
- comment
- discussion
