DOCS-1841 - Update Search Job API docs

[JV0812]

Purpose of this pull request

Combines the legacy Search Job API and the new OpenAPI-based Search Job Management API into a single doc (docs/api/search-job.md), instead of two separate pages, with a shared section for concepts common to both (prerequisites, required role capabilities, result limits, rate limits, process flow, errors) and dedicated sections for what's specific to each version:

• Legacy Search Job API: endpoints for API access, session timeout, GET/POST/DELETE methods, bash script.
• Search Job Management API: OpenAPI/Swagger region table, and an MSSP tip on the new childOrgIds/includeAllChildOrgs parameters.

Also:

• Cross-links Search Across Child Orgs (MSSPs) to the new API so MSSP users know they can run multi-org searches programmatically, not just through the Search UI.
• Adds a release note announcing the _orgName field for multi-child-org search results, and mentioning the programmatic option.

Verified via yarn build (no broken links/anchors) after each change.

Select the type of change

• Minor Changes - Typos, formatting, slight revisions
• Update Content - Revisions, updating sections
• New Content - New features, sections, pages, tutorials
• Site and Tools - .clabot, version updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

Ticket (if applicable)

https://sumologic.atlassian.net/browse/DOCS-1841

[amee-sumo]

Reviewed the full diff — clean restructuring, no blocking issues.

Verified:

• All internal links/anchors across the repo that point into search-job.md (7 docs + 2 blog posts) still resolve — heading text didn't change, only nesting level, so slugs are stable.
• No orphaned second page — the "instead of two separate pages" framing refers to a design decision made within this branch itself, not a leftover doc.
• <ApiIntro/> relocation into the new "Search Job Management API" section is correct — its content is OpenAPI/Swagger-specific and doesn't apply to the Legacy API.
• The _orgName field the new release note announces is already documented in search-across-child-orgs.md, so the note isn't ahead of the docs.
• toc_max_heading_level: 4 is a legitimate Docusaurus option, justified by the doc's new 4-level heading depth.

Minor nit, not blocking: the bash script code block has some trailing-whitespace-only diff noise (e.g. the PROTOCOL=$1 ... lines look unchanged but show as modified). Harmless since it's in a code fence, but worth a quick cleanup pass if you touch this file again.

[kimsauce]

Review

Solid restructure and the mechanics check out (anchors, frontmatter, conventions). Two things worth resolving before merge, both content-accuracy rather than formatting.

Should fix before merge

1. "Shared" sections still carry legacy-only session semantics

Everything above the ## Legacy Search Job API split is presented as common to both versions, but some of it is specific to the cookie/session model that the PR itself says the new API doesn't use ("doesn't require session cookies to keep a search job alive between requests"):

• Process flow step 3: "This needs to be done at least every 20-30 seconds so the search session is not canceled due to inactivity."
• Rate limit throttling: "If the search job is not kept alive by API requests every 20-30 seconds, it is canceled."

A reader landing on the Search Job Management API (the one we're recommending) will reasonably conclude they must poll every 20–30s to avoid cancellation. Please confirm whether keepalive/inactivity-cancellation and the 8-hour query timeout apply to the Management API; if they're legacy-only, scope those sentences to the Legacy section or add a qualifying note. The ## Session timeout section is already correctly moved under Legacy — this is just the two references that leaked into the shared area.

2. Release note backdated a month

blog-service/2026-09-01-search.md was renamed to blog-service/2026-08-01-search.md. Today is 2026-09-01 and the sibling search notes are dated 08-17 and 08-27, so an 08-01 date drops this announcement ~30 entries deep in the blog feed on publish. If the _orgName feature GA'd on a specific earlier date that's intentional — otherwise this should be 2026-09-01 (or the actual GA date).

Nits (non-blocking)

• Thin new section. ## Search Job Management API has no endpoint or parameter reference at all — not even childOrgIds / includeAllChildOrgs beyond the tip — everything defers to Swagger. That's consistent with other Swagger-only API docs (log-searches.md, dashboard.md), so it's acceptable, but the asymmetry with the fully inline legacy section is stark for the version we're recommending. Consider a short parameter note.
• "The previous/old version." Drop the slash: "The earlier version."
• "less performant" (appears twice) — prefer "slower" or "lower performance."
• The bash script block has whitespace-only churn (trailing-space/reindent) mixed into the diff — harmless but noisy.

Verified OK

• toc_max_heading_level: 4 is the right addition — methods drop to h4 under the new nesting, and this keeps them in the right-hand TOC without pulling in the h5 sub-parts.
• Inbound anchors still resolve: #create-a-search-job and #rate-limit-throttling (external links from use-searchable-time.md, searching-data-tiers.md, blog-service/2025/12-31.md), and in-page #delete-a-search-job / #process-flow.
• New in-page anchors (#search-job-management-api, #legacy-search-job-api) and the cross-links from the release note and search-across-child-orgs.md all match.
• Blog frontmatter matches the blog-service convention (title case + category, keywords, image, hide_table_of_contents).
• Cross-links are bidirectional and correctly scoped.

_{🤖 Generated with Claude Code}

[kimsauce]

Inline notes for the findings from my summary comment above.