from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
+- `from`: Optional id from which to start selection.
+- `take`: The total amount of entries to retrieve when using the from parameter. Defaults to 50.
+
+**Note**: The first time you call this endpoint using checkpoint pagination, omit the `from` parameter. If there are more results, a `next` value is included in the response. You can use this for subsequent API calls. When `next` is no longer included in the response, no pages are remaining.
body.
+Creates a new connection according to the JSON object received in `body`.
-Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+**Note:** If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
+**Note**: If you use the `options` parameter, the entire `options` object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
ID. 200 OK http status code response is returned when the connection is online, otherwise a 404 status code is returned along with an error message
+Retrieves the status of an ad/ldap connection referenced by its `ID`. `200 OK` http status code response is returned when the connection is online, otherwise a `404` status code is returned along with an error message
custom_client_ip_header for a domain, the body to
+**Updating CUSTOM_CLIENT_IP_HEADER for a custom domain**
+
+To update the `custom_client_ip_header` for a domain, the body to
send should be:
-{ "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
-{ "tls_policy": "recommended" }compatible TLS policy is no longer supported.
+- The `compatible` TLS policy is no longer supported.
@@ -4431,12 +4436,12 @@ client.customDomains().test("id");
Run the verification process on a custom domain.
-Note: Check the status field to see its verification status. Once verification is complete, it may take up to 10 minutes before the custom domain can start accepting requests.
+Note: Check the `status` field to see its verification status. Once verification is complete, it may take up to 10 minutes before the custom domain can start accepting requests.
-For self_managed_certs, when the custom domain is verified for the first time, the response will also include the cname_api_key which you will need to configure your proxy. This key must be kept secret, and is used to validate the proxy requests.
+For `self_managed_certs`, when the custom domain is verified for the first time, the response will also include the `cname_api_key` which you will need to configure your proxy. This key must be kept secret, and is used to validate the proxy requests.
-Learn more about verifying custom domains that use Auth0 Managed certificates.
-Learn more about verifying custom domains that use Self Managed certificates.
+[Learn more](https://auth0.com/docs/custom-domains#step-2-verify-ownership) about verifying custom domains that use Auth0 Managed certificates.
+[Learn more](https://auth0.com/docs/custom-domains/self-managed-certificates#step-2-verify-ownership) about verifying custom domains that use Self Managed certificates.
@@ -6816,7 +6821,7 @@ client.groups().delete("id");
q parameter, or search from a specific log ID ("search from checkpoint").
+Set custom search criteria using the `q` parameter, or search from a specific log ID (_"search from checkpoint"_).
-For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
+For more information on all possible event types, their respective acronyms, and descriptions, see [Log Event Type Codes](https://auth0.com/docs/logs/log-event-type-codes).
-fields and sort, see Searchable Fields.
+For more information on the list of fields that can be used in `fields` and `sort`, see [Searchable Fields](https://auth0.com/docs/logs/log-search-query-syntax#searchable-fields).
-Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
+Auth0 [limits the number of logs](https://auth0.com/docs/logs/retrieve-log-events-using-mgmt-api#limitations) you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the [get logs by checkpoint method](https://auth0.com/docs/logs/retrieve-log-events-using-mgmt-api#retrieve-logs-by-checkpoint).
-take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.from and take will be ignored, and date ordering is not guaranteed.
+**Important:** When fetching logs from a checkpoint log ID, any parameter other than `from` and `take` will be ignored, and date ordering is not guaranteed.
@@ -9365,6 +9367,318 @@ client.prompts().updateSettings(
+
+
+
+
+## RateLimitPolicies
+client.rateLimitPolicies.list() -> SyncPagingIterable<RateLimitPolicy>client.rateLimitPolicies.create(request) -> CreateRateLimitPolicyResponseContentclient.rateLimitPolicies.get(id) -> GetRateLimitPolicyResponseContentclient.rateLimitPolicies.delete(id)client.rateLimitPolicies.update(id, request) -> UpdateRateLimitPolicyResponseContentlogin_success can change the rule's function signature to have user omitted.
+Note: Changing a rule's stage of execution from the default `login_success` can change the rule's function signature to have user omitted.
q query parameter can be used to get users that match the specified criteria using query string syntax.
-Learn more about searching for users.
-Read about best practices when working with the API endpoints for retrieving users.
-Auth0 limits the number of users you can return. If you exceed this threshold, please redefine your search, use the export job, or the User Import / Export extension.
+The `q` query parameter can be used to get users that match the specified criteria [using query string syntax.](https://auth0.com/docs/users/search/v3/query-syntax)
+
+[Learn more about searching for users.](https://auth0.com/docs/users/search/v3)
+
+Read about [best practices](https://auth0.com/docs/users/search/best-practices) when working with the API endpoints for retrieving users.
+
+
+
+Auth0 limits the number of users you can return. If you exceed this threshold, please redefine your search, use the [export job](https://auth0.com/docs/api/management/v2#!/Jobs/post_users_exports), or the [User Import / Export](https://auth0.com/docs/extensions/user-import-export) extension.
@@ -13641,9 +13959,9 @@ client.users().list(
connection is required but other parameters such as email and password are dependent upon the type of connection.
+Note: `connection` is required but other parameters such as `email` and `password` are dependent upon the type of connection.
user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
-{ "user_metadata" : { "profileCode": 1479 } }addresses the body to send should be:
-{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}user_metadata property:{
+```json
+{
"user_metadata": {
"profileCode": 1479,
"addresses": { "work_address": "100 Industrial Way" }
}
-}"home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
-{
+```json
+{
"user_metadata": {
"addresses": {
"work_address": "100 Industrial Way",
"home_address": "742 Evergreen Terrace"
}
}
-}user_metadata property:
-{
+```json
+{
"user_metadata": {
"profileCode": 1479,
"addresses": {
@@ -14119,7 +14457,8 @@ The modified object ends up with the following user_metadata proper
"home_address": "742 Evergreen Terrace"
}
}
-}When content-type header is set to application/json:
+When `content-type` header is set to `application/json`:
+
+```json
{
- "template": "<!DOCTYPE html>{% assign resolved_dir = dir | default: "auto" %}<html lang="{{locale}}" dir="{{resolved_dir}}"><head>{%- auth0:head -%}</head><body class="_widget-auto-layout">{%- auth0:widget -%}</body></html>"
+ "template": "{% assign resolved_dir = dir | default: \"auto\" %}{%- auth0:head -%}{%- auth0:widget -%}"
}
-
+```
-
- When content-type header is set to text/html:
-
-<!DOCTYPE html>
+When `content-type` header is set to `text/html`:
+
+```html
+
{% assign resolved_dir = dir | default: "auto" %}
-<html lang="{{locale}}" dir="{{resolved_dir}}">
- <head>
+
+
{%- auth0:head -%}
- </head>
- <body class="_widget-auto-layout">
+
+
{%- auth0:widget -%}
- </body>
-</html>
-
+
+
+```
@@ -19088,7 +19427,7 @@ client.connections().scimConfiguration().list(
connectionId.
+Retrieves a scim configuration by its `connectionId`.
connectionId.
+Deletes a scim configuration by its `connectionId`.
connectionId.
+Update a scim configuration by its `connectionId`.
connectionId.
+Retrieves a scim configuration's default mapping by its `connectionId`.
from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no further results are remaining.
+**Note**: The first time you call this endpoint, omit the `from` parameter. If there are more results, a `next` value is included in the response. You can use this for subsequent API calls. When `next` is no longer included in the response, no further results are remaining.
id.
+Retrieves all scim tokens by its connection `id`.
id and tokenId.
+Deletes a scim token by its connection `id` and `tokenId`.
client.groups.roles.list(id) -> SyncPagingIterable<Role>client.groups.roles.create(id, request)client.groups.roles.delete(id, request)all-applications policy prompts with MFA for all logins.confidence-score policy prompts with MFA only for low confidence logins.confidence-score policy is part of the Adaptive MFA feature. Adaptive MFA requires an add-on for the Enterprise plan; review Auth0 Pricing for more details.
+- `all-applications` policy prompts with MFA for all logins.
+- `confidence-score` policy prompts with MFA only for low confidence logins.
+
+**Note**: The `confidence-score` policy is part of the [Adaptive MFA feature](https://auth0.com/docs/secure/multi-factor-authentication/adaptive-mfa). Adaptive MFA requires an add-on for the Enterprise plan; review [Auth0 Pricing](https://auth0.com/pricing) for more details.
all-applications policy prompts with MFA for all logins.confidence-score policy prompts with MFA only for low confidence logins.confidence-score policy is part of the Adaptive MFA feature. Adaptive MFA requires an add-on for the Enterprise plan; review Auth0 Pricing for more details.
+- `all-applications` policy prompts with MFA for all logins.
+- `confidence-score` policy prompts with MFA only for low confidence logins.
+
+**Note**: The `confidence-score` policy is part of the [Adaptive MFA feature](https://auth0.com/docs/secure/multi-factor-authentication/adaptive-mfa). Adaptive MFA requires an add-on for the Enterprise plan; review [Auth0 Pricing](https://auth0.com/pricing) for more details.
from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
+- `from`: Optional id from which to start selection.
+- `take`: The total amount of entries to retrieve when using the from parameter. Defaults to 50.
+
+**Note**: The first time you call this endpoint using checkpoint pagination, omit the `from` parameter. If there are more results, a `next` value is included in the response. You can use this for subsequent API calls. When `next` is no longer included in the response, no pages are remaining.
update:current_user_identities scope:
-
- POST /api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities
- Authorization: "Bearer PRIMARY_ACCOUNT_JWT"
- {
- "link_with": "SECONDARY_ACCOUNT_JWT"
- }
-
- In this case, only the link_with param is required in the body, which also contains the JWT obtained upon the secondary account's authentication.
- update:users scope:
-
- POST /api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities
- Authorization: "Bearer YOUR_API_V2_TOKEN"
- {
- "provider": "SECONDARY_ACCOUNT_PROVIDER",
- "connection_id": "SECONDARY_ACCOUNT_CONNECTION_ID(OPTIONAL)",
- "user_id": "SECONDARY_ACCOUNT_USER_ID"
- }
-
- In this case you need to send provider and user_id in the body. Optionally you can also send the connection_id param which is suitable for identifying a particular database connection for the 'auth0' provider.
- This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
body.
- * Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public CompletableFuturebody.
- * Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public CompletableFutureNote: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public CompletableFutureNote: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public CompletableFutureNote: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
body.
- * Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public CompletableFutureNote: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public CompletableFutureNote: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public CompletableFutureNote: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public CompletableFutureNote: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public CompletableFutureNote: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -82,7 +81,6 @@ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -101,7 +99,6 @@ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -120,7 +117,6 @@ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -661,57 +657,65 @@ public void onFailure(@NotNull Call call, @NotNull IOException e) { /** * Update a user. *These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -719,7 +723,8 @@ public void onFailure(@NotNull Call call, @NotNull IOException e) {
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -786,7 +799,8 @@ public CompletableFuture> u
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -854,7 +876,8 @@ public CompletableFuture> u
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -922,7 +953,8 @@ public CompletableFuture> u
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public CompletableFutureNote: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public CompletableFutureNote: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -126,7 +125,6 @@ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -144,7 +142,6 @@ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -162,7 +159,6 @@ public CompletableFuture<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -255,57 +251,65 @@ public CompletableFutureThese are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -313,7 +317,8 @@ public CompletableFuture delete(String id, RequestOptions requestOptions)
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -380,7 +393,8 @@ public CompletableFuture update(String id) {
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -447,7 +469,8 @@ public CompletableFuture update(String id, RequestOpt
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -514,7 +545,8 @@ public CompletableFuture update(String id, UpdateUser
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
body.
- * Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public CreateConnectionResponseContent create(CreateConnectionRequestContent request) { return this.rawClient.create(request).body(); @@ -145,7 +145,7 @@ public CreateConnectionResponseContent create(CreateConnectionRequestContent req /** * Creates a new connection according to the JSON object received inbody.
- * Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public CreateConnectionResponseContent create( CreateConnectionRequestContent request, RequestOptions requestOptions) { @@ -183,7 +183,7 @@ public GetConnectionResponseContent get( /** * Removes a specific connection from your tenant. This action cannot be undone. Once removed, users can no longer use this connection to authenticate. - *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public void delete(String id) { this.rawClient.delete(id).body(); @@ -191,7 +191,7 @@ public void delete(String id) { /** * Removes a specific connection from your tenant. This action cannot be undone. Once removed, users can no longer use this connection to authenticate. - *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public void delete(String id, RequestOptions requestOptions) { this.rawClient.delete(id, requestOptions).body(); @@ -199,7 +199,7 @@ public void delete(String id, RequestOptions requestOptions) { /** * Update details for a specific connection, including option properties for identity provider configuration. - *Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
This endpoint supports two types of pagination:
- *Checkpoint pagination must be used if you need to retrieve more than 1000 connections.
- *Checkpoint Pagination
*To search by checkpoint, use the following parameters:
- *from: Optional id from which to start selection.take: The total amount of entries to retrieve when using the from parameter. Defaults to 50.Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
Note: The first time you call this endpoint using checkpoint pagination, omit the from parameter. If there are more results, a next value is included in the response. You can use this for subsequent API calls. When next is no longer included in the response, no pages are remaining.
body.
- * Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public ManagementApiHttpResponsebody.
- * Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
+ *Note: If a connection with the same name was recently deleted and had a large number of associated users, the deletion may still be processing. Creating a new connection with that name before the deletion completes may fail or produce unexpected results.
*/ public ManagementApiHttpResponseNote: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public ManagementApiHttpResponseNote: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
+ *Note: If your connection has a large amount of users associated with it, please be aware that this operation can be long running after the response is returned and may impact concurrent create connection requests, if they use an identical connection name.
*/ public ManagementApiHttpResponseNote: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overriden. To avoid partial data or other issues, ensure all parameters are present when using this option.
Note: If you use the options parameter, the entire options object is overridden. To avoid partial data or other issues, ensure all parameters are present when using this option.
custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*custom_client_ip_header for a domain, the body to
- * send should be:
- * { "custom_client_ip_header": "cf-connecting-ip" }tls_policy for a domain, the body to send should be:
- * { "tls_policy": "recommended" }Updating CUSTOM_CLIENT_IP_HEADER for a custom domain
+ *To update the custom_client_ip_header for a domain, the body to
+ * send should be:
{ "custom_client_ip_header": "cf-connecting-ip" }
+ * Updating TLS_POLICY for a custom domain
+ *To update the tls_policy for a domain, the body to send should be:
{ "tls_policy": "recommended" }
+ * TLS Policies:
*Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
Set custom search criteria using the q parameter, or search from a specific log ID ("search from checkpoint").
For more information on all possible event types, their respective acronyms, and descriptions, see Log Event Type Codes.
- *To set custom search criteria, use the following parameters:
+ *:1 for ascending and :-1 for descending. e.g. date:-1For more information on the list of fields that can be used in fields and sort, see Searchable Fields.
Auth0 limits the number of logs you can return by search criteria to 100 logs per request. Furthermore, you may paginate only through 1,000 search results. If you exceed this threshold, please redefine your search or use the get logs by checkpoint method.
- *To search from a checkpoint log ID, use the following parameters:
*take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.take parameter. If you use from at the same time as q, from takes precedence and q is ignored.from parameter.Important: When fetching logs from a checkpoint log ID, any parameter other than from and take will be ignored, and date ordering is not guaranteed.
Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public ManagementApiHttpResponseNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public ManagementApiHttpResponseNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public ManagementApiHttpResponseNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public ManagementApiHttpResponseNote: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public ManagementApiHttpResponseNote: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public ManagementApiHttpResponse<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -77,7 +76,6 @@ public ManagementApiHttpResponse<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -95,7 +93,6 @@ public ManagementApiHttpResponse<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -113,7 +110,6 @@ public ManagementApiHttpResponse<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -530,57 +526,65 @@ public ManagementApiHttpResponseThese are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -588,7 +592,8 @@ public ManagementApiHttpResponse delete(String id, RequestOptions requestO
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -655,7 +668,8 @@ public ManagementApiHttpResponse update(String id) {
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -722,7 +744,8 @@ public ManagementApiHttpResponse update(String id, Re
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -789,7 +820,8 @@ public ManagementApiHttpResponse update(String id, Up
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public SyncPagingIterableNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public SyncPagingIterableNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public SyncPagingIterableNote: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
+ *Note: The returned list does not include standard roles available for tenant members, such as Admin or Support Access.
*/ public SyncPagingIterableNote: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public CreateRoleResponseContent create(CreateRoleRequestContent request) { return this.rawClient.create(request).body(); @@ -83,7 +83,7 @@ public CreateRoleResponseContent create(CreateRoleRequestContent request) { /** * Create a user role for Role-Based Access Control. - *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
+ *Note: New roles are not associated with any permissions by default. To assign existing permissions to your role, review Associate Permissions with a Role. To create new permissions, review Add API Permissions.
*/ public CreateRoleResponseContent create(CreateRoleRequestContent request, RequestOptions requestOptions) { return this.rawClient.create(request, requestOptions).body(); diff --git a/src/main/java/com/auth0/client/mgmt/UserAttributeProfilesClient.java b/src/main/java/com/auth0/client/mgmt/UserAttributeProfilesClient.java index 7db326ab..7ba9b9ca 100644 --- a/src/main/java/com/auth0/client/mgmt/UserAttributeProfilesClient.java +++ b/src/main/java/com/auth0/client/mgmt/UserAttributeProfilesClient.java @@ -63,14 +63,14 @@ public SyncPagingIterable<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -125,7 +124,6 @@ public SyncPagingIterable<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -143,7 +141,6 @@ public SyncPagingIterable<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -161,7 +158,6 @@ public SyncPagingIterable<!-- only v3 is available -->
*The q query parameter can be used to get users that match the specified criteria using query string syntax.
Learn more about searching for users.
*Read about best practices when working with the API endpoints for retrieving users.
@@ -252,57 +248,65 @@ public void delete(String id, RequestOptions requestOptions) { /** * Update a user. *These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -310,7 +314,8 @@ public void delete(String id, RequestOptions requestOptions) {
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -377,7 +390,8 @@ public UpdateUserResponseContent update(String id) {
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -444,7 +466,8 @@ public UpdateUserResponseContent update(String id, RequestOptions requestOptions
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * These are the attributes that can be updated at the root level:
- *Some considerations:
- *user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.{ "email_verified": true }user_metadata:
- * { "user_metadata" : { "profileCode": 1479 } }user_metadata and app_metadata). These properties are merged instead of being replaced but be careful, the merge only occurs on the first level.email, email_verified, phone_number, phone_verified, username or password of a secondary identity, you need to specify the connection property too.email or phone_number you can specify, optionally, the client_id property.email_verified is not supported for enterprise and passwordless sms connections.blocked to false does not affect the user's blocked state from an excessive amount of incorrectly provided credentials. Use the "Unblock a user" endpoint from the "User Blocks" API to change the user's state.null as the value.Updating a field (non-metadata property)
+ *To mark the email address of a user as verified, the body to send should be:
+ *{ "email_verified": true }
+ * Updating a user metadata root property
+ *Let's assume that our test user has the following user_metadata:
{ "user_metadata" : { "profileCode": 1479 } }
+ * To add the field addresses the body to send should be:
{ "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}The modified object ends up with the following user_metadata property:
{
- * "user_metadata": {
- * "profileCode": 1479,
- * "addresses": { "work_address": "100 Industrial Way" }
+ * { "user_metadata" : { "addresses": {"work_address": "100 Industrial Way"} }}
+ *
+ * The modified object ends up with the following user_metadata property:
+ * {
+ * "user_metadata": {
+ * "profileCode": 1479,
+ * "addresses": { "work_address": "100 Industrial Way" }
+ * }
* }
- * }
- * Updating an inner user metadata property
If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
- * {
+ *
+ * Updating an inner user metadata property
+ * If there's existing user metadata to which we want to add "home_address": "742 Evergreen Terrace" (using the addresses property) we should send the whole addresses object. Since this is a first-level object, the object will be merged in, but its own properties will not be. The body to send should be:
+ * {
* "user_metadata": {
* "addresses": {
* "work_address": "100 Industrial Way",
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * The modified object ends up with the following user_metadata property:
{
+ * {
* "user_metadata": {
* "profileCode": 1479,
* "addresses": {
@@ -511,7 +542,8 @@ public UpdateUserResponseContent update(String id, UpdateUserRequestContent requ
* "home_address": "742 Evergreen Terrace"
* }
* }
- * }
+ * }
+ * When content-type header is set to application/json:
- * {
- * "template": "<!DOCTYPE html>{% assign resolved_dir = dir | default: "auto" %}<html lang="{{locale}}" dir="{{resolved_dir}}"><head>{%- auth0:head -%}</head><body class="_widget-auto-layout">{%- auth0:widget -%}</body></html>"
+ * When content-type header is set to application/json:
+ * {
+ * "template": "<!DOCTYPE html>{% assign resolved_dir = dir | default: \"auto\" %}<html lang=\"{{locale}}\" dir=\"{{resolved_dir}}\"><head>{%- auth0:head -%}</head><body class=\"_widget-auto-layout\">{%- auth0:widget -%}</body></html>"
* }
- *
- *
- * When content-type header is set to text/html:
- *
- *
- * <!DOCTYPE html>
+ *
+ * When content-type header is set to text/html:
+ * <!DOCTYPE html>
* {% assign resolved_dir = dir | default: "auto" %}
- * <html lang="{{locale}}" dir="{{resolved_dir}}">
- * <head>
+ * <html lang="{{locale}}" dir="{{resolved_dir}}">
+ * <head>
* {%- auth0:head -%}
- * </head>
- * <body class="_widget-auto-layout">
+ * </head>
+ * <body class="_widget-auto-layout">
* {%- auth0:widget -%}
- * </body>
- * </html>
- *
+ * </body>
+ * </html>
+ *
*/
public CompletableFutureWhen content-type header is set to application/json:
- * {
- * "template": "<!DOCTYPE html>{% assign resolved_dir = dir | default: "auto" %}<html lang="{{locale}}" dir="{{resolved_dir}}"><head>{%- auth0:head -%}</head><body class="_widget-auto-layout">{%- auth0:widget -%}</body></html>"
+ * When content-type header is set to application/json:
+ * {
+ * "template": "<!DOCTYPE html>{% assign resolved_dir = dir | default: \"auto\" %}<html lang=\"{{locale}}\" dir=\"{{resolved_dir}}\"><head>{%- auth0:head -%}</head><body class=\"_widget-auto-layout\">{%- auth0:widget -%}</body></html>"
* }
- *
- *
- * When content-type header is set to text/html:
- *
- *
- * <!DOCTYPE html>
+ *
+ * When content-type header is set to text/html:
+ * <!DOCTYPE html>
* {% assign resolved_dir = dir | default: "auto" %}
- * <html lang="{{locale}}" dir="{{resolved_dir}}">
- * <head>
+ * <html lang="{{locale}}" dir="{{resolved_dir}}">
+ * <head>
* {%- auth0:head -%}
- * </head>
- * <body class="_widget-auto-layout">
+ * </head>
+ * <body class="_widget-auto-layout">
* {%- auth0:widget -%}
- * </body>
- * </html>
- *
+ * </body>
+ * </html>
+ *
*/
public CompletableFutureWhen