diff --git a/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-connection-handlers.adoc b/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-connection-handlers.adoc
index e4e7ae9101..4a9b65ea92 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-connection-handlers.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-connection-handlers.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -1251,7 +1251,8 @@ When more than one authentication mechanism is specified, mechanisms are applied
 
 There are many possibilities when configuring HTTP authorization mechanisms. __This procedure shows only one OAuth 2.0 example.__
 
-The example that follows demonstrates an OpenDJ directory server configured for tests (insecure connections) to request OAuth 2.0 token information from OpenAM. Download ForgeRock Access Management or OpenAM software from link:https://backstage.forgerock.com/downloads/[https://backstage.forgerock.com/downloads/, window=\_top].
+The example that follows demonstrates an OpenDJ directory server configured for tests (insecure connections) to request OAuth 2.0 token information from OpenAM.
+Download OpenAM software from link:https://github.com/OpenIdentityPlatform/OpenAM/releases[https://github.com/OpenIdentityPlatform/OpenAM/releases, window=\_top].
 
 [#d67723e3953]
 .Settings for OAuth 2.0 Example With OpenAM
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-monitoring.adoc b/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-monitoring.adoc
index 00c968394c..596b8a58fb 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-monitoring.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-monitoring.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -40,7 +40,7 @@ OpenDJ control panel provides basic monitoring capabilities under Monitoring > G
 
 OpenDJ exposes monitoring information over LDAP under the entry `cn=monitor`. Many different types of information are exposed. The following example shows monitoring information about the `userRoot` backend holding Example.com data:
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)
 
 [source, console]
 ----
@@ -163,7 +163,7 @@ SNMPv2-SMI::mib-2.66.1.1.2.1 = STRING: "/path/to/opendj"
 
 OpenDJ provides JMX-based monitoring. A number of tools support JMX, including `jconsole` and `jvisualvm`, which are bundled with the Sun/Oracle Java platform. JMX is not configured by default. Use the `dsconfig` command to configure the JMX connection handler:
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)
 
 Configure the server to activate JMX access. The following example uses the reserved port number, 1689:
 
@@ -301,7 +301,7 @@ example-20110623030000000  Backup  Waiting on start time
 
 By default OpenDJ stores access and errors logs, and a server process ID file under the `logs/` directory. For the replication service, OpenDJ also keeps a replication log there. You can also configure a debug log. You can also configure policies about how logs are rotated, and how they are retained. You configure logging using the `dsconfig` command.
 
-Each log depends on a __log publisher__, whose type corresponds to the type of log. OpenDJ provides a number of file-based log publishers out of the box, and supports the ForgeRock common audit event framework, sometimes referred to as Common Audit. The ForgeRock common audit event framework provides log handlers for publishing to CSV files, relational databases, and the UNIX system log (Syslog) as described in xref:#log-common-audit["Common ForgeRock Access Logs"]. The framework makes it possible to plug in additional handlers as well.
+Each log depends on a __log publisher__, whose type corresponds to the type of log. OpenDJ provides a number of file-based log publishers out of the box, and supports the Open Identity Platform common audit event framework, sometimes referred to as Common Audit. The ForgeRock common audit event framework provides log handlers for publishing to CSV files, relational databases, and the UNIX system log (Syslog) as described in xref:#log-common-audit["Common ForgeRock Access Logs"]. The framework makes it possible to plug in additional handlers as well.
 
 [#log-access]
 ==== Access Logs
@@ -325,14 +325,14 @@ Notice that by default OpenDJ directory server logs a message for the search req
 
 
 [#log-common-audit]
-==== Common ForgeRock Access Logs
+==== Common Open Identity Platform Access Logs
 
-In addition to the default file-based access log formats, OpenDJ directory server supports the ForgeRock common audit event framework. OpenDJ uses the framework to write access logs in formats that are compatible with all products using the framework. The framework uses transaction IDs that make it easy to correlate requests as they traverse the platform. This makes it easier to monitor activity and to enrich reports.
+In addition to the default file-based access log formats, OpenDJ directory server supports the Open Identity Platform common audit event framework. OpenDJ uses the framework to write access logs in formats that are compatible with all products using the framework. The framework uses transaction IDs that make it easy to correlate requests as they traverse the platform. This makes it easier to monitor activity and to enrich reports.
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)
 
-The ForgeRock common audit event framework is built around audit event handlers. Audit event handlers can encapsulate their own configurations. Audit event handlers are the same in each product in the ForgeRock platform. As a result, you can plug in custom handlers that comply with the framework without having to upgrade OpenDJ directory server.
-The ForgeRock common audit event framework includes handlers for logging audit event messages to local files and facilities, as well as to remote systems. Handlers for the following are supported:
+The Open Identity Platform common audit event framework is built around audit event handlers. Audit event handlers can encapsulate their own configurations. Audit event handlers are the same in each product in the Open Identity Platform. As a result, you can plug in custom handlers that comply with the framework without having to upgrade OpenDJ directory server.
+The Open Identity Platform common audit event framework includes handlers for logging audit event messages to local files and facilities, as well as to remote systems. Handlers for the following are supported:
 
 * CSV files, with support for tamper-evident logs.
 +
@@ -350,7 +350,7 @@ You configure the JDBC handler as an external log publisher that logs access mes
 +
 Although it is rarely used for access events, you can configure the Syslog handler as an external log publisher that logs access messages to the UNIX Syslog facility.
 
-The ForgeRock common audit event framework supports a variety of audit event topics. OpenDJ currently supports handling for access events, which are system boundary events such as the initial request and final response to that request. In other words, the implementation in OpenDJ is focused only on access logging. Based on the connection handler for the request, OpenDJ divides access events into `ldap-access` events and `http-access` events.
+The Open Identity Platform common audit event framework supports a variety of audit event topics. OpenDJ currently supports handling for access events, which are system boundary events such as the initial request and final response to that request. In other words, the implementation in OpenDJ is focused only on access logging. Based on the connection handler for the request, OpenDJ divides access events into `ldap-access` events and `http-access` events.
 To enable common audit-based logging, follow one of these procedures:
 
 * xref:#log-common-audit-ldap-csv["To Enable LDAP CSV Access Logs"]
@@ -692,7 +692,7 @@ $ dsconfig \
 [#log-common-audit-trust-transaction-ids]
 .To Trust Transaction IDs
 ====
-Client applications using the ForgeRock common audit event framework send transaction IDs with their requests. The transaction IDs are used to correlate audit events for monitoring and reporting that trace the request through multiple applications.
+Client applications using the Open Identity Platform common audit event framework send transaction IDs with their requests. The transaction IDs are used to correlate audit events for monitoring and reporting that trace the request through multiple applications.
 
 Transaction IDs are sent over LDAP using an internal OpenDJ request control. They are sent over HTTP in an HTTP header.
 
@@ -1702,7 +1702,7 @@ The following `errors` log excerpt shows log entries for a backup task, with lin
 
 For the HTTP Connection Handler, OpenDJ maintains a separate access log in `logs/http-access`. This access log, by default configured as the File Based HTTP Access Log Publisher, uses a different format than the LDAP access log. This HTTP access log uses link:http://www.w3.org/TR/WD-logfile.html[Extended Log File Format, window=\_blank] with fields described in link:http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/676400bc-8969-4aa7-851a-9319490a9bbb.mspx?mfr=true[Microsoft's implementation, window=\_blank] as well.
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)
 --
 The following default fields are shown here in the order they occur in the log file:
 
@@ -1755,7 +1755,7 @@ When using this field to match HTTP requests with internal operations in the LDA
 Execution time in milliseconds needed by OpenDJ to service the HTTP request
 
 `x-transaction-id`::
-ForgeRock common audit event framework transaction ID for the request
+Open Identity Platform common audit event framework transaction ID for the request
 
 +
 This defaults to `0` unless you configure OpenDJ to trust transaction IDs as described in xref:#log-common-audit-trust-transaction-ids["To Trust Transaction IDs"].
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-install.adoc b/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-install.adoc
index 0acb05fbe5..f8d3db69c2 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-install.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-install.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -62,7 +62,7 @@ If your default Java environment is not appropriate, set `OPENDJ_JAVA_HOME` to t
 +
 Antivirus and intrusion detection systems that do a deep inspection of database files are not compatible with OpenDJ directory server. Disable antivirus and intrusion detection systems, or at least prevent them from operating on OpenDJ directory server files.
 
-. Download enterprise software releases through the ForgeRock link:https://backstage.forgerock.com/[BackStage, window=\_blank] site. ForgeRock enterprise releases are thoroughly validated builds for ForgeRock customers who run OpenDJ in production deployments, and for those who want to try or test with release builds.
+. Download software releases from the link:https://github.com/OpenIdentityPlatform/OpenDJ/releases[GitHub, window=\_blank].
 +
 --
 The following OpenDJ 3.5.3 server software is available:
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-upgrade.adoc b/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-upgrade.adoc
index 0602eaceff..189c413695 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-upgrade.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-upgrade.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -25,7 +25,7 @@
 
 This chapter covers upgrade from previous versions.
 
-If the OpenDJ directory server version is older than 2.6.0, you must upgrade your deployment to use at least OpenDJ directory server 2.6.0 before following the procedures in this chapter. For details on upgrading to that version, see link:https://backstage.forgerock.com/docs/opendj/2.6/install-guide/#chap-upgrade[Upgrading to OpenDJ 2.6.0, window=\_blank].
+If the OpenDJ directory server version is older than 2.6.0, you must upgrade your deployment to use at least OpenDJ directory server 2.6.0 before following the procedures in this chapter.
 
 [TIP]
 ====
@@ -70,7 +70,7 @@ To move to a newer version, edit the `default.java-home` setting in the `opendj/
 
 . (Optional)  If you are upgrading to OpenDJ OEM edition from OpenDJ 2.6, make sure there is enough disk space to export all of the data to LDIF files.
 
-. Download enterprise software releases through the ForgeRock link:https://backstage.forgerock.com/[BackStage, window=\_blank] site. ForgeRock enterprise releases are thoroughly validated builds for ForgeRock customers who run OpenDJ in production deployments, and for those who want to try or test with release builds.
+. Download enterprise releases from the link:https://github.com/OpenIdentityPlatform/OpenDJ/releases[GitHub, window=\_blank] site.
 
 . (Optional)  If you are upgrading OpenDJ directory server on Windows, and OpenDJ is registered as a Windows service, disable OpenDJ as a Windows service before upgrade, as in the following example:
 +
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap-3-0.adoc b/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap-3-0.adoc
index 3459c110cb..2fde87b71b 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap-3-0.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap-3-0.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -38,7 +38,7 @@ OpenDJ offers two alternatives for RESTful access to directory data:
 --
 The JSON format configuration can hold the following configuration objects. Some of the configuration settings are available only in the REST LDAP gateway configuration. The order here is the order shown in the default configuration file:
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"])
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"])
 
 "ldapConnectionFactories" (required, gateway only)::
 Configures how the gateway connects to LDAP servers. This entire configuration object applies only to the REST to LDAP gateway.
@@ -198,7 +198,7 @@ Default: "default"
 The gateway authenticates by simple bind using the credentials specified:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "authentication": {
@@ -334,10 +334,10 @@ Specifies how to handle LDAP authorization. The following values are supported:
 
 
 "proxyAuthzIdTemplate" (gateway only)::
-Specifies the template to derive the authorization ID from the security context created during authentication. Use `{dn}` to indicate the user's bind DN or `{id}` to indicate the user name provided for authentication.
+Specifies the template to derive the authorization ID from the security context created during authentication. Use `\{dn\}` to indicate the user's bind DN or `\{id\}` to indicate the user name provided for authentication.
 
 +
-Default: "dn:{dn}"
+Default: "dn:\{dn\}"
 
 "mappings"::
 For each collection URI such as `/users` and `/groups`, you configure a mapping between the JSON resource returned over HTTP, and the LDAP entry returned by the directory service.
@@ -401,7 +401,7 @@ The following naming strategies are supported:
 * RDN and resource ID are both derived from a single user attribute in the LDAP entry, as in the following example, where the `uid` attribute is the RDN and its value is the JSON resource ID:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "namingStrategy": {
@@ -414,7 +414,7 @@ The following naming strategies are supported:
 * RDN and resource ID are derived from separate user attributes in the LDAP entry, as in the following example where the RDN attribute is `uid` but the JSON resource ID is the value of the `mail` attribute:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "namingStrategy": {
@@ -428,7 +428,7 @@ The following naming strategies are supported:
 * RDN is derived from a user attribute and the resource ID from an operational attribute in the LDAP entry, as in the following example, where the RDN attribute is `uid` but the JSON resource ID is the value of the `entryUUID` operational attribute:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "namingStrategy": {
@@ -444,7 +444,7 @@ The following naming strategies are supported:
 LDAP attributes to include during LDAP add operations as an array of type-value lists, such as the following example:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "additionalLDAPAttributes": [
@@ -476,7 +476,7 @@ Maps a single JSON attribute to a fixed value.
 This can be useful as in the default case where each JSON resource "schemas" takes the SCIM URN, and so the value is not related to the underlying LDAP entries:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "schemas": {
@@ -494,7 +494,7 @@ Maps a JSON field to an LDAP attribute.
 Simple mappings are used where the correspondence between JSON fields and LDAP attributes is one-to-one:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "userName": {
@@ -555,7 +555,7 @@ Maps a JSON field to an LDAP entry found by reference.
 This mapping works for LDAP attributes whose values reference other entries. This is shown in the following example from the default configuration. The LDAP `manager` attribute values are user entry DNs. Here, the JSON `manager` field takes the user ID and name from the entry referenced by the LDAP attribute. On updates, changes to the JSON manager `_id` affect which manager entry is referenced, yet any changes to the manager's name are discarded, because changing managers only affects which user entry to point to, not the referenced user's name:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "manager": {
@@ -589,7 +589,7 @@ This mapping works for LDAP attributes whose values reference other entries. Thi
 Babs Jensen's manager in the sample LDAP data is Torrey Rigden, who has user ID `trigden`. Babs's entry has `manager: uid=trigden,ou=People,dc=example,dc=com`. With this mapping, the resulting JSON field is the following:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "manager": [
@@ -631,7 +631,7 @@ Default: `false`
 The default mappings expose a SCIM view of user and group data:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "/users": {
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap.adoc b/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap.adoc
index 2649d83a54..2adc96b029 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -30,7 +30,7 @@ OpenDJ offers two alternatives for access to directory data over HTTP:
 
 * The OpenDJ REST to LDAP gateway runs in a Servlet container independent from the directory service. You configure the gateway to access the directory service by editing configuration files for the gateway web application.
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"])
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"])
 
 [NOTE]
 ====
@@ -246,7 +246,7 @@ By default, the gateway connects to the directory server listening on port 1389
 The gateway accesses this array of LDAP servers if primary LDAP servers cannot be contacted. These might be LDAP servers in the same remote data center, for example:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "secondaryLdapServers": [
@@ -282,7 +282,7 @@ Default: `bind`
 The gateway authenticates by simple bind using the credentials specified:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "authentication": {
@@ -411,13 +411,13 @@ Default: `bind`
 The template to produce the bind DN from the HTTP Basic user name.
 
 +
-A single occurrence of the string `{username}` is replaced in the template with the HTTP Basic user name.
+A single occurrence of the string `\{username\}` is replaced in the template with the HTTP Basic user name.
 
 +
-For example, if the user name is also the UID of the LDAP entry, use `uid={username},ou=People,dc=example,dc=com`.
+For example, if the user name is also the UID of the LDAP entry, use `uid=\{username\},ou=People,dc=example,dc=com`.
 
 +
-Default: `{username}`
+Default: `\{username\}`
 
 ========
 
@@ -438,13 +438,13 @@ Default: `bind`
 The template to produce the authorization ID from the HTTP Basic user name.
 
 +
-A single occurrence of the string `{username}` is replaced in the template with the HTTP Basic user name.
+A single occurrence of the string `\{username\}` is replaced in the template with the HTTP Basic user name.
 
 +
-If the user name is also the authorization ID, use `u:{username}`.
+If the user name is also the authorization ID, use `u:\{username\}`.
 
 +
-If the user name is the LDAP bind DN, use `dn:{username}`.
+If the user name is the LDAP bind DN, use `dn:\{username\}`.
 
 ========
 
@@ -483,10 +483,10 @@ Use `sub` for a subtree search, `one` for a one-level search.
 The template for the filter of the LDAP search.
 
 +
-A single occurrence of the string `{username}` is replaced in the template with the HTTP Basic user name.
+A single occurrence of the string `\{username\}` is replaced in the template with the HTTP Basic user name.
 
 +
-If the user name is also the UID, use `(&(uid={username})(objectClass=inetOrgPerson))`.
+If the user name is also the UID, use `(&(uid=\{username\})(objectClass=inetOrgPerson))`.
 
 ========
 
@@ -581,7 +581,7 @@ A JSON pointer value in braces is replaced in the template with a field value fr
 This template must start with `u:` or `dn:`.
 
 +
-For example, if token resolution returns a JSON document where the value of the `uid` field is the UID of the user entry in the directory, you might use `u:{uid}` or `dn:{uid},ou=People,dc=example,dc=com`.
+For example, if token resolution returns a JSON document where the value of the `uid` field is the UID of the user entry in the directory, you might use `u:\{uid\}` or `dn:\{uid\},ou=People,dc=example,dc=com`.
 
 ========
 
@@ -631,13 +631,13 @@ A JSON pointer value in braces is replaced in the template with a field value fr
 This template must start with `u:` or `dn:`.
 
 +
-For example, if token resolution returns a JSON document where the value of the `username` field is the UID of the user entry in the directory, you might use `u:{username}` or `dn:{username},ou=People,dc=example,dc=com`.
+For example, if token resolution returns a JSON document where the value of the `username` field is the UID of the user entry in the directory, you might use `u:\{username\}` or `dn:\{username\},ou=People,dc=example,dc=com`.
 
 `cts`::
 Configuration for resolving OAuth 2.0 tokens when the directory service acts as OpenAM's CTS store.
 
 +
-OpenAM's CTS store is constrained to a specific layout. The `authzIdTemplate` must therefore use `{userName/0}` for the user identifier.
+OpenAM's CTS store is constrained to a specific layout. The `authzIdTemplate` must therefore use `\{userName/0}` for the user identifier.
 
 +
 This mechanism makes it possible to resolve access tokens by making a request to the CTS directory service, without making a request to OpenAM. __This mechanism does not, however, ensure that the token requested will have already been replicated to the directory server where the request is routed.__
@@ -848,7 +848,7 @@ For example, suppose LDAP entries for devices are located under the following ba
 
 * `ou=tablets,ou=devices,dc=example,dc=com`
 
-The subresource name `/{type}` would be substituted in actual paths with `/others`, `/pcs`, `/phones`, and `/tablets`. The DN template for the subresource would specify `ou={type},ou=devices,dc=example,dc=com` in order to locate the entries in the correct LDAP organizational unit. In the example, REST to LDAP substitutes `{type}` in the DN template with the type defined in the request URL path.
+The subresource name `/\{type\}` would be substituted in actual paths with `/others`, `/pcs`, `/phones`, and `/tablets`. The DN template for the subresource would specify `ou=\{type\},ou=devices,dc=example,dc=com` in order to locate the entries in the correct LDAP organizational unit. In the example, REST to LDAP substitutes `\{type\}` in the DN template with the type defined in the request URL path.
 
 For details on subresource configuration, see xref:#rest-subresource-properties["Sub-Resource Properties"].
 
@@ -1091,7 +1091,7 @@ The following naming strategies are supported:
 * RDN and resource ID are both derived from a single user attribute in the LDAP entry, as in the following example, where the `uid` attribute is the RDN and its value is the JSON resource ID:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "namingStrategy": {
@@ -1104,7 +1104,7 @@ The following naming strategies are supported:
 * RDN and resource ID are derived from separate user attributes in the LDAP entry, as in the following example, where the RDN attribute is `uid`, but the JSON resource ID is the value of the `mail` attribute:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "namingStrategy": {
@@ -1118,7 +1118,7 @@ The following naming strategies are supported:
 * RDN is derived from a user attribute and the resource ID from an operational attribute in the LDAP entry, as in the following example, where the RDN attribute is `uid`, but the JSON resource ID is the value of the `entryUUID` operational attribute:
 +
 
-[source, javascript]
+[source, json]
 ----
 {
     "namingStrategy": {
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations-3-0.adoc b/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations-3-0.adoc
index 80be4bd1f6..3b89b42019 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations-3-0.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations-3-0.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -51,9 +51,9 @@ In this chapter, you will learn how to use the OpenDJ REST API that provides acc
 
 Before trying the examples, enable HTTP access to OpenDJ directory server as described in xref:../admin-guide/chap-connection-handlers.adoc#setup-rest2ldap-3-0["RESTful Client Access (3.0)"] in the __Administration Guide__. The examples in this chapter use HTTP, but the procedure also shows how to set up HTTPS access to the server.
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.)
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.)
 
-The OpenDJ REST API is built on a common ForgeRock HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations. For an overview of ForgeRock common REST APIs, see xref:chap-rest-operations.adoc#sec-about-crest["About ForgeRock Common REST"].
+The OpenDJ REST API is built on a common Open Identity Platform HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations. For an overview of Open Identity Platform common REST APIs, see xref:chap-rest-operations.adoc#sec-about-crest["About Common REST"].
 
 [#authenticate-rest-3-0]
 === Authenticating Over REST (3.0)
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations.adoc b/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations.adoc
index 7c7c18690e..45495a082a 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -53,14 +53,14 @@ In this chapter, you will learn how to use the OpenDJ REST API that provides acc
 
 Before trying the examples, enable HTTP access to OpenDJ directory server as described in xref:../admin-guide/chap-connection-handlers.adoc#setup-rest2ldap-endpoint["To Set Up REST Access to User Data"] in the __Administration Guide__. (If you are using OpenDJ 3.0, see xref:../admin-guide/chap-connection-handlers.adoc#setup-rest2ldap-3-0["RESTful Client Access (3.0)"] in the __Administration Guide__ instead.) The examples in this chapter use HTTP, but the procedure also shows how to set up HTTPS access to the server.
 
-Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.)
+Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.)
 
-The OpenDJ REST API is built on a common ForgeRock HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations.
+The OpenDJ REST API is built on a common Open Identity Platform HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations.
 
 [#sec-about-crest]
-=== About ForgeRock Common REST
+=== About Common REST
 
-For many REST APIs that are not defined by external standards, ForgeRock products provide common ways to access web resources and collections of resources. This section covers what is common across products. Adapt the examples to your types of resources and to your deployment.
+For many REST APIs that are not defined by external standards, Open Identity Platform products provide common ways to access web resources and collections of resources. This section covers what is common across products. Adapt the examples to your types of resources and to your deployment.
 
 [#about-crest-resources]
 ==== Common REST Resources
@@ -375,7 +375,7 @@ PATCH operations apply to three types of targets:
 
 * *set semantics array*, where the elements are not ordered, and duplicates are not allowed.
 
-ForgeRock PATCH supports several different `operations`. The following sections show each of these operations, along with options for the `field` and `value`:
+Open Identity Platform PATCH supports several different `operations`. The following sections show each of these operations, along with options for the `field` and `value`:
 
 [#crest-patch-add]
 ===== Patch Operation: Add
@@ -396,7 +396,7 @@ An `add` operation has different results on two standard types of arrays:
 
 As an example, start with the following list semantic array resource:
 
-[source, javascript]
+[source, json]
 ----
 {
     "fruits" : [ "orange", "apple" ]
@@ -404,7 +404,7 @@ As an example, start with the following list semantic array resource:
 ----
 The following add operation includes the pineapple to the end of the list of fruits, as indicated by the `-` at the end of the `fruits` array.
 
-[source, javascript]
+[source, json]
 ----
 {
     "operation" : "add",
@@ -414,7 +414,7 @@ The following add operation includes the pineapple to the end of the list of fru
 ----
 The following is the resulting resource:
 
-[source, javascript]
+[source, json]
 ----
 {
     "fruits" : [ "orange", "apple", "pineapple" ]
@@ -429,7 +429,7 @@ The copy operation takes one or more existing values from the source field. It t
 
 The following `copy` operation takes the value from the source named `/hot/potato`, and then runs a `replace` operation on the target value, `/hot/tamale`.
 
-[source, javascript]
+[source, json]
 ----
 [
   {
@@ -447,7 +447,7 @@ If the source and value are configured as arrays, the result depends on whether
 
 The `increment` operation changes the value or values of the target field by the amount you specify. The value that you include must be one number, and may be positive or negative. The value of the target field must accept numbers. The following `increment` operation adds `1000` to the target value of `/user/payment`.
 
-[source, javascript]
+[source, json]
 ----
 [
   {
@@ -467,7 +467,7 @@ The move operation removes existing values on the source field. It then adds tho
 
 The following `move` operation is equivalent to a `remove` operation on the source named `/hot/potato`, followed by a `replace` operation on the target value, `/hot/tamale`.
 
-[source, javascript]
+[source, json]
 ----
 [
   {
@@ -485,7 +485,7 @@ To apply a `move` operation on an array, you need a compatible single-value, lis
 
 The `remove` operation ensures that the target field no longer contains the value provided. If the remove operation does not include a value, the operation removes the field. The following `remove` deletes the value of the `phoneNumber`, along with the field.
 
-[source, javascript]
+[source, json]
 ----
 [
   {
@@ -500,7 +500,7 @@ A `remove` operation has different results on two standard types of arrays:
 * *List semantic arrays*: A `remove` operation deletes the specified element in the array. For example, the following operation removes the first phone number, based on its array index (zero-based):
 +
 
-[source, javascript]
+[source, json]
 ----
 [
    {
@@ -521,7 +521,7 @@ The `replace` operation removes any existing value(s) of the targeted field, and
 
 The following `replace` operation removes the existing `telephoneNumber` value for the user, and then adds the new value of `+1 408 555 9999`.
 
-[source, javascript]
+[source, json]
 ----
 [
   {
@@ -533,15 +533,15 @@ The following `replace` operation removes the existing `telephoneNumber` value f
 ----
 A PATCH replace operation on a list semantic array works in the same fashion as a PATCH remove operation. The following example demonstrates how the effect of both operations. Start with the following resource:
 
-[source, javascript]
+[source, json]
 ----
 {
-    "fruits" : [ "apple", "orange", "kiwi", "lime" ],
+    "fruits" : [ "apple", "orange", "kiwi", "lime" ]
 }
 ----
 Apply the following operations on that resource:
 
-[source, javascript]
+[source, json]
 ----
 [
   {
@@ -562,7 +562,7 @@ The PATCH operations are applied sequentially. The `remove` operation removes th
 ----
 [
   {
-    "fruits" : [ "orange", "kiwi", "lime" ],
+    "fruits" : [ "orange", "kiwi", "lime" ]
   }
 ]
 ----
@@ -583,7 +583,7 @@ The second PATCH operation, a `replace`, is applied on the second member (`fruit
 
 The `transform` operation changes the value of a field based on a script or some other data transformation command. The following `transform` operation takes the value from the field named `/objects`, and applies the `something.js` script as shown:
 
-[source, javascript]
+[source, json]
 ----
 [
   {
@@ -595,7 +595,7 @@ The `transform` operation changes the value of a field based on a script or some
         "file" : "something.js"
       }
     }
-  },
+  }
 ]
 ----
 
@@ -2306,7 +2306,7 @@ Notice the following features of the responses:
 [#mime-types-rest]
 === Working With Alternative Content Types
 
-OpenDJ generally maps JSON resources to LDAP entries. Some resources such as profile photos, however, are best expressed with other MIME types. ForgeRock common REST lets your applications make HTTP multipart requests, so you can work with other MIME types differently from regular JSON resources. This is done using the `_mimeType` parameter described in xref:#about-crest-read["Read"].
+OpenDJ generally maps JSON resources to LDAP entries. Some resources such as profile photos, however, are best expressed with other MIME types. Open Identity Platform common REST lets your applications make HTTP multipart requests, so you can work with other MIME types differently from regular JSON resources. This is done using the `_mimeType` parameter described in xref:#about-crest-read["Read"].
 This section includes the following procedures:
 
 * xref:#mime-types-rest-mapping["To Map an Alternative Content Type"]
diff --git a/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-writing-plugins.adoc b/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-writing-plugins.adoc
index 671306ece4..104e9ff098 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-writing-plugins.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-writing-plugins.adoc
@@ -12,7 +12,7 @@
   information: "Portions copyright [year] [name of copyright owner]".
  
   Copyright 2017 ForgeRock AS.
-  Portions Copyright 2024 3A Systems LLC.
+  Portions Copyright 2024-2025 3A Systems LLC.
 ////
 
 :figure-caption!:
@@ -35,9 +35,9 @@ In this chapter you will learn:
 
 [IMPORTANT]
 ====
-ForgeRock supports customers using standard plugins delivered as part of OpenDJ directory server.
+Open Identity Platform Approved Vendors support customers using standard plugins delivered as part of OpenDJ directory server.
 
-If you deploy with custom plugins and need support in production, contact link:mailto:info\@forgerock.com[info@forgerock.com, window=\_top] in advance to determine how your deployment can be supported.
+If you deploy with custom plugins and need support in production, see link:https://github.com/OpenIdentityPlatform/.github/wiki/Approved-Vendor-List[Approved Vendors List, window=\_top] in advance to determine how your deployment can be supported.
 ====
 
 [#about-server-plugins]
@@ -47,7 +47,7 @@ OpenDJ directory server plugins are Java libraries compiled against the OpenDJ l
 
 [NOTE]
 ====
-The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.
+The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.
 
 This means that a server plugin built with one version of OpenDJ directory server will not necessarily work or even compile with a different version of the server.
 ====
@@ -256,7 +256,7 @@ This version of the example plugin project is new in OpenDJ directory server 3.5
 The OpenDJ example server plugin is an Apache Maven project.
 
 As you can see in the `pom.xml` file for the project, the plugin depends on the OpenDJ directory server module.
-The plugin project uses these ForgeRock Maven plugins:
+The plugin project uses these Open Identity Platform Maven plugins:
 
 * The `i18n-maven-plugin` generates message source files from properties files in the resource bundle.
 +
@@ -338,7 +338,7 @@ The plugin implementation is found in `src/main/java/com/example/opendj/ExampleP
 
 [NOTE]
 ====
-The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.
+The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.
 
 This means that a server plugin built with one version of OpenDJ directory server will not necessarily work or even compile with a different version of the server.
 ====