POST /api/v1/users/{userId}/factors
Enrolls a supported Factor for the specified user
Note: All responses return the enrolled Factor with a status of either
PENDING_ACTIVATION`` or
ACTIVE`.
Additional SMS/Call Factor information
- Rate limits: Okta may return a
429 Too Many Requests
status code if you attempt to resend an SMS or a voice call challenge (OTP) within the same time window. The current rate limit is one SMS/CALL challenge per phone number every 30 seconds. - Existing phone numbers: Okta may return a
400 Bad Request
status code if a user attempts to enroll with a different phone number when the user has an existing mobile phone or has an existing phone with voice call capability. A user can enroll only one mobile phone forsms
and enroll only one voice call capable phone forcall
factor.
Additional WebAuthn Factor information
Enroll WebAuthn response parameters
-
For detailed information on the Webauthn standard, including an up-to-date list of supported browsers, see webauthn.me.
-
In the enroll API response, the
response._embedded.activation
object contains properties used to help the client to create a new WebAuthn credential for use with Okta. See the WebAuthn spec for PublicKeyCredentialCreationOptions.
Additional Custom TOTP Factor information
Enroll Custom TOTP Factor
-
The enrollment process involves passing both the
factorProfileId
andsharedSecret
properties for a token. -
A Factor Profile represents a particular configuration of the Custom TOTP factor. It includes certain properties that match the hardware token that end users possess, such as the HMAC algorithm, passcode length, and time interval. There can be multiple Custom TOTP factor profiles per org, but users can only enroll in one Custom TOTP factor. Admins can create Custom TOTP factor profiles in the Admin Console. Then, copy the
factorProfileId
from the Admin Console into the API request. -
For Custom TOTP enrollment, Okta automaticaly enrolls a user with a
token:software:totp
factor and thepush
factor if the user isn't currently enrolled with these factors.
Servers
- https://{yourOktaDomain}
Path parameters
Name | Type | Required | Description |
---|---|---|---|
userId |
String | Yes |
ID of an existing Okta user |
Request headers
Name | Type | Required | Description |
---|---|---|---|
Content-Type |
String | Yes |
The media type of the request body.
Default value: "application/json" |
Accept-Language |
String | No |
An ISO 639-1 two-letter language code that defines a localized message to send. This parameter is only used by |
Query parameters
Name | Type | Required | Description |
---|---|---|---|
updatePhone |
Boolean | No |
If Default value: false |
templateId |
String | No |
ID of an existing custom SMS template. See the SMS Templates API. This parameter is only used by |
activate |
Boolean | No |
If Default value: false |
tokenLifetimeSeconds |
Integer | No |
Defines how long the token remains valid Default value: 300 |
Request body fields
Name | Type | Required | Description |
---|---|---|---|
id |
String | No |
ID of the Factor |
profile |
Object | No |
Specific attributes related to the Factor |
provider |
String | No |
Provider for the Factor Possible values:
|
_embedded |
Object | No | |
created |
String | No |
Timestamp when the Factor was enrolled |
vendorName |
String | No |
Name of the Factor vendor. This is usually the same as the provider except for On-Prem MFA where it depends on administrator settings. |
status |
String | No |
Status of the Factor Possible values:
|
factorType |
String | No |
Type of Factor Possible values:
|
lastUpdated |
String | No |
Timestamp when the Factor was last updated |
How to start integrating
- Add HTTP Task to your workflow definition.
- Search for the API you want to integrate with and click on the name.
- This loads the API reference documentation and prepares the Http request settings.
- Click Test request to test run your request to the API and see the API's response.