Merge pull request #337 from HeidiSteen/main

prmerger-automator[bot] · web-flow · commit 726611fc65a7 · 2024-09-17T22:21:53.000Z
BULK EDIT: documents
diff --git a/articles/search/query-odata-filter-orderby-syntax.md b/articles/search/query-odata-filter-orderby-syntax.md
@@ -93,7 +93,7 @@ Field paths are used in many parameters of the [Azure AI Search REST APIs](/rest
 | [Suggest](/rest/api/searchservice/suggestions) and [Autocomplete](/rest/api/searchservice/documents/autocomplete-post) | `searchFields` | Can only refer to fields that are part of a [suggester](index-add-suggesters.md) |
 | [Search](/rest/api/searchservice/documents/search-post), [Suggest](/rest/api/searchservice/suggestions), and [Autocomplete](/rest/api/searchservice/documents/autocomplete-post) | `$filter` | Can only refer to **filterable** fields |
 | [Search](/rest/api/searchservice/documents/search-post) and [Suggest](/rest/api/searchservice/suggestions) | `$orderby` | Can only refer to **sortable** fields |
-| [Search](/rest/api/searchservice/documents/search-post), [Suggest](/rest/api/searchservice/suggestions), and [Lookup](/rest/api/searchservice/lookup-document) | `$select` | Can only refer to **retrievable** fields |
+| [Search](/rest/api/searchservice/documents/search-post), [Suggest](/rest/api/searchservice/suggestions), and [Lookup](/rest/api/searchservice/documents/get) | `$select` | Can only refer to **retrievable** fields |
 
 ## Constants
 
diff --git a/articles/search/search-add-autocomplete-suggestions.md b/articles/search/search-add-autocomplete-suggestions.md
@@ -58,7 +58,7 @@ Follow these links for the REST and .NET SDK reference pages:
 
 ## Structure a response
 
-Responses for autocomplete and suggestions are what you might expect for the pattern: [Autocomplete](/rest/api/searchservice/documents/autocomplete-post#responses) returns a list of terms, [Suggestions](/rest/api/searchservice/suggestions#response) returns terms plus a document ID so that you can fetch the document (use the [Lookup Document](/rest/api/searchservice/lookup-document) API to fetch the specific document for a detail page).
+Responses for autocomplete and suggestions are what you might expect for the pattern: [Autocomplete](/rest/api/searchservice/documents/autocomplete-post#responses) returns a list of terms, [Suggestions](/rest/api/searchservice/suggestions#response) returns terms plus a document ID so that you can fetch the document (use the [Lookup Document](/rest/api/searchservice/documents/get) API to fetch the specific document for a detail page).
 
 Responses are shaped by the parameters on the request:
 
diff --git a/articles/search/search-howto-reindex.md b/articles/search/search-howto-reindex.md
@@ -150,7 +150,7 @@ If indexing workloads introduce unacceptable levels of query latency, conduct [p
 
 ## Check for updates
 
-You can begin querying an index as soon as the first document is loaded. If you know a document's ID, the [Lookup Document REST API](/rest/api/searchservice/lookup-document) returns the specific document. For broader testing, you should wait until the index is fully loaded, and then use queries to verify the context you expect to see.
+You can begin querying an index as soon as the first document is loaded. If you know a document's ID, the [Lookup Document REST API](/rest/api/searchservice/documents/get) returns the specific document. For broader testing, you should wait until the index is fully loaded, and then use queries to verify the context you expect to see.
 
 You can use [Search Explorer](search-explorer.md) or a [REST client](search-get-started-rest.md) to check for updated content.
 
diff --git a/articles/search/search-performance-tips.md b/articles/search/search-performance-tips.md
@@ -61,7 +61,7 @@ Query composition and complexity are one of the most important factors for perfo
 
 + **Number of searchable fields.** Each additional searchable field results in more work for the search service. You can limit the fields being searched at query time using the "searchFields" parameter. It's best to specify only the fields that you care about to improve performance.
 
-+ **Amount of data being returned.** Retrieving a large amount content can make queries slower. When structuring a query, return only those fields that you need to render the results page, and then retrieve remaining fields using the [Lookup API](/rest/api/searchservice/lookup-document) once a user selects a match.
++ **Amount of data being returned.** Retrieving a large amount content can make queries slower. When structuring a query, return only those fields that you need to render the results page, and then retrieve remaining fields using the [Lookup API](/rest/api/searchservice/documents/get) once a user selects a match.
 
 + **Use of partial term searches.** [Partial term searches](search-query-partial-matching.md), such as prefix search, fuzzy search, and regular expression search, are more computationally expensive than typical keyword searches, as they require full index scans to produce results.
 
diff --git a/articles/search/search-query-overview.md b/articles/search/search-query-overview.md
@@ -74,7 +74,7 @@ For more information and examples, see [Geospatial search example](search-query-
 
 ## Document look-up
 
-In contrast with the previously described query forms, this one retrieves a single [search document by ID](/rest/api/searchservice/lookup-document), with no corresponding index search or scan. Only the one document is requested and returned. When a user selects an item in search results, retrieving the document and populating a details page with fields is a typical response, and a document look-up is the operation that supports it.
+In contrast with the previously described query forms, this one retrieves a single [search document by ID](/rest/api/searchservice/documents/get), with no corresponding index search or scan. Only the one document is requested and returned. When a user selects an item in search results, retrieving the document and populating a details page with fields is a typical response, and a document look-up is the operation that supports it.
 
 ## Advanced search: fuzzy, wildcard, proximity, regex
 
diff --git a/articles/search/semantic-answers.md b/articles/search/semantic-answers.md
@@ -120,7 +120,7 @@ When designing a search results page that includes answers, be sure to handle ca
 
 Within @search.answers:
 
-+ **"key"** is the document key or ID of the match. Given a document key, you can use [Lookup Document](/rest/api/searchservice/lookup-document) API to retrieve any or all parts of the search document to include on the search page or a detail page.
++ **"key"** is the document key or ID of the match. Given a document key, you can use [Lookup Document](/rest/api/searchservice/documents/get) API to retrieve any or all parts of the search document to include on the search page or a detail page.
 
 + **"text"** and **"highlights"** provide identical content, in both plain text and with highlights. 
 
diff --git a/articles/search/tutorial-optimize-indexing-push-api.md b/articles/search/tutorial-optimize-indexing-push-api.md
@@ -365,7 +365,7 @@ You can explore the populated search index after the program has run programmati
 
 ### Programatically
 
-There are two main options for checking the number of documents in an index: the [Count Documents API](/rest/api/searchservice/count-documents) and the [Get Index Statistics API](/rest/api/searchservice/get-index-statistics). Both paths require time to process so don't be alarmed if the number of documents returned is initially lower than you expect.
+There are two main options for checking the number of documents in an index: the [Count Documents API](/rest/api/searchservice/documents/count) and the [Get Index Statistics API](/rest/api/searchservice/get-index-statistics). Both paths require time to process so don't be alarmed if the number of documents returned is initially lower than you expect.
 
 #### Count Documents
 
