> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbitsearch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> New features and improvements to the Orbit API.

Follow API updates in your own tools by subscribing to the
[RSS feed](https://docs.orbitsearch.com/changelog/rss.xml). In Slack, install
the RSS app and run
`/feed subscribe https://docs.orbitsearch.com/changelog/rss.xml` in any
channel to receive new entries as they publish.

## August 2026

<Update label="August 26, 2026" description="Watchers and webhooks API" rss={{ title: "Watchers and Webhooks API" }}>
  **Watchers and Webhooks API**

  * **Watch a profile from the API**: `POST /v3/watchers` refreshes a profile on your schedule and appends what it finds; list, read, pause, retime and delete watchers, and read every run's outcome and changes with `GET /v3/watchers/{watcher_id}/runs`.
  * **Webhooks**: `POST /v3/webhooks` registers an HTTPS endpoint that receives signed `profile.updated` deliveries when a run finds new information.
  * New scopes: `watchers:write` and `webhooks:write`.

  See [Create a watcher →](/api/watchers/create) and [Webhook events →](/api/webhooks/events). Read the launch post: [Introducing Watchers →](https://developer.orbitsearch.com/blog/introducing-profile-watchers)
</Update>

<Update label="August 25, 2026" description="Directory watchers and verifiable timeline events" rss={{ title: "Directory Watchers and Verifiable Timeline Events" }}>
  **Directory Watchers and Verifiable Timeline Events**

  * **Watch a whole directory**: in the dashboard, a directory's **Watchers** tab watches any or all of its people on one schedule, with a default schedule and default checks per directory.
  * **Updates feed**: the same tab lists every dated event for every directory member, newest first, with the sources behind each one.
  * **Activity for members**: people who can open a directory see an **Activity** view of those events beside search, with unread markers.
  * **Dates carry their precision**: every `eventsTimeline` item now has `datePrecision` (`day`, `month`, `year`) and `dateBasis` (`stated`, `published`, `inferred`), and `date` is served at that precision — a month is `2026-08`.
  * **Sources on every event**: each event's `sources` are the pages it comes from — up to three, with the supporting excerpt when the page has one.
  * **Cleaner timelines**: the timeline holds happenings and published content; `updateCount` and `lastUpdatedAt` change when an event gains new information or a new date.

  See [Read Profile →](/api/enrich/read-profile#profile-sections)
</Update>

<Update label="August 12, 2026" description="Image evidence" rss={{ title: "Image Source Evidence" }}>
  **Image Source Evidence**

  * **Photos as evidence**: section items can now cite the photo that supports them. The source carries the supporting image in `images`, with the origin post as `link`.

  See [Read Profile →](/api/enrich/read-profile#source-object)
</Update>

<Update label="August 11, 2026" description="Per-item source evidence" rss={{ title: "Per-Section Source Evidence" }}>
  **Per-Section Source Evidence**

  * **Item-level sources**: every profile section item can now carry its own `sources` array: the exact sources that support that specific item, each with excerpt `chunks` from the source text.
  * **Personal life and worldview**: these sections include per-item evidence for the first time.

  See [Read Profile →](/api/enrich/read-profile#source-object)
</Update>

<Update label="August 7, 2026" description="Independent result limits" rss={{ title: "Independent Result Limits" }}>
  **Independent Result Limits**

  * **Per-lane limits**: search result limits now apply independently per result lane, so one lane filling up no longer caps the others.

  See [Search →](/api/search/search)
</Update>

<Update label="August 6, 2026" description="Precise search statuses" rss={{ title: "Precise Search Statuses" }}>
  **Precise Search Statuses**

  * **Every status defined**: each result status now has a precise definition, with per-phase completion fields and the exact moment it appears.
  * **Final means final**: `candidate_discovery_completed` now guarantees the result list is complete.

  See [Search Status →](/api/search/search-status)
</Update>

## July 2026

<Update label="July 29, 2026" description="Result stability guarantees" rss={{ title: "Result Stability Guarantees" }}>
  **Result Stability Guarantees**

  * **Append-only results**: a result never disappears or moves backward while you poll.
  * **Alias IDs**: candidate profiles expose alias IDs, so every ID you collect stays resolvable.

  See [Search Status →](/api/search/search-status)
</Update>

<Update label="July 23, 2026" description="Interactive API playground" rss={{ title: "Interactive API Playground" }}>
  **Interactive API Playground**

  * **Try it in the docs**: the reference pages gained an interactive playground and a downloadable OpenAPI spec.
  * **Full read contract**: the v3 profile read response now follows a complete, stable contract.

  See [Read Profile →](/api/enrich/read-profile)
</Update>

<Update label="July 22, 2026" description="Live discovered sources" rss={{ title: "Live Discovered Sources" }}>
  **Live Discovered Sources**

  * **Sources as they arrive**: candidate discovery status responses show the sources Orbit is reading as it finds them, including sources that are still pending.

  See [Search Status →](/api/search/search-status)
</Update>

<Update label="July 20, 2026" description="Plain-English queries" rss={{ title: "Plain-English Queries" }}>
  **Plain-English Queries**

  * **Just describe the person**: Search accepts a plain-English `query` field, and Orbit splits it into structured intent for you.

  See [Search →](/api/search/search)
</Update>

<Update label="July 18, 2026" description="v3 Search and Enrich APIs" rss={{ title: "v3 Search and Enrich" }}>
  **v3 Search and Enrich**

  * **One surface, two jobs**: the v3 surface is live: one Search API for finding people and one Enrich API for deepening known profiles.
  * **v2 retirement**: earlier v2 endpoints are deprecated. We encourage you to migrate to the v3 endpoint contract by following our migration guide.

  See [Migration Guide →](/guides/migrate-v2-to-v3)
</Update>

<Update label="July 16, 2026" description="Progressive results" rss={{ title: "Progressive Results" }}>
  **Progressive Results**

  * **Render as it builds**: deep searches return partial results while generation continues.
</Update>

<Update label="July 14, 2026" description="Search workflow endpoints" rss={{ title: "Search Workflows" }}>
  **Search Workflows**

  * **One managed flow**: a workflow start endpoint plus a status endpoint run a full search end to end. These later merged into the v3 Search API.
</Update>

<Update label="July 12, 2026" description="Regeneration contract" rss={{ title: "Regeneration Contract" }}>
  **Regeneration Contract**

  * **Explicit semantics**: full regenerations rebuild from a clean slate, and partial runs continue from existing content.

  See [Enrich Profile →](/api/enrich/enrich-profile)
</Update>

<Update label="July 2, 2026" description="Regeneration run shapes" rss={{ title: "Regeneration Run Shapes" }}>
  **Regeneration Run Shapes**

  * **Full rebuilds**: the `full_regeneration` run shape rebuilds a known profile end to end.
  * **Candidate depth**: `candidateChildRunShape` controls how deeply candidate profiles generate during discovery.
</Update>

<Update label="July 1, 2026" description="Higher rate limits" rss={{ title: "Higher Rate Limits" }}>
  **Higher Rate Limits**

  * **More headroom**: rate limits increased across Search and profile reads.

  See [Rate Limits →](/concepts/rate-limits)
</Update>

## June 2026

<Update label="June 24, 2026" description="Faster partial profiles" rss={{ title: "Faster Partial Profiles" }}>
  **Faster Partial Profiles**

  * **Slim first, then backfill**: the `partial_only` run shape delivers a slim profile fast and backfills the rest automatically.
</Update>

<Update label="June 16, 2026" description="Candidate discovery" rss={{ title: "Candidate Discovery" }}>
  **Candidate Discovery**

  * **Find groups of people**: the `candidate_discovery` run shape finds matching people from one description.
  * **Per-second buckets**: rate limits moved to per-second buckets with burst capacity.

  See [Rate Limits →](/concepts/rate-limits)
</Update>

<Update label="June 15, 2026" description="Clear failure reporting" rss={{ title: "Structured Failures" }}>
  **Structured Failures**

  * **Structured failures**: failed runs return a `failure` object with codes such as `identity_not_corroborated` and explicit retry guidance.
  * **Richer results**: search results include more metadata, including a short `bio`.
</Update>

<Update label="June 12, 2026" description="Consolidated profile images" rss={{ title: "Consolidated Profile Images" }}>
  **Consolidated Profile Images**

  * **One images section**: profile images merged into a single person-qualified `images` section with roles and per-image sources.

  See [Read Profile →](/api/enrich/read-profile)
</Update>

<Update label="June 11, 2026" description="One canonical profile ID" rss={{ title: "Canonical Profile IDs" }}>
  **Canonical Profile IDs**

  * **Single ID**: responses consolidated on a canonical `payload.id`, and aliases from older reads keep resolving to the same profile.
  * **Regenerate by ID**: a `profileId` input regenerates a known profile.
</Update>

<Update label="June 9, 2026" description="Poll-only status contract" rss={{ title: "Poll-Only Status Contract" }}>
  **Poll-Only Status Contract**

  * **v3 contract**: profile generation moved to a `runShape` input, a `requestId` for every run, and one status endpoint to poll.
  * **Profile search**: a dedicated endpoint queries within a single profile.
</Update>

<Update label="June 5, 2026" description="Durable profile aliases" rss={{ title: "Durable Profile Aliases" }}>
  **Durable Profile Aliases**

  * **IDs that last**: when profiles merge, old IDs become aliases that keep resolving to the canonical profile.
</Update>

<Update label="June 3, 2026" description="More seed inputs" rss={{ title: "More Seed Inputs" }}>
  **More Seed Inputs**

  * **Seed with what you have**: generation accepts `phoneNumber`, `urls`, and `usernames` seeds, plus a candidate discovery mode for finding groups of people.
</Update>

<Update label="June 1, 2026" description="Partial profiles" rss={{ title: "Partial Profiles" }}>
  **Partial Profiles**

  * **Show something early**: the `partialProfile` flag and the `partial_profile_ready` stage surface a useful profile before the full run completes.
</Update>

## May 2026

<Update label="May 28, 2026" description="Structured profile sections" rss={{ title: "Structured Profile Sections" }}>
  **Structured Profile Sections**

  * **Structured items**: profile sections moved to a structured `items` format.
  * **Contribution sections**: research papers, GitHub repositories, media, music, and books joined the profile.
</Update>

<Update label="May 22, 2026" description="Structured intent" rss={{ title: "Structured Intent" }}>
  **Structured Intent**

  * **Semantic clauses**: deep searches accept structured intent with semantic clauses.
  * **One search endpoint**: Smart Search consolidated onto a single endpoint.
</Update>

<Update label="May 21, 2026" description="Seeded searches" rss={{ title: "Seeded Searches" }}>
  **Seeded Searches**

  * **Email and LinkedIn seeds**: searches accept identity seeds for higher precision.
  * **Why it matched**: `includeMatchReason` explains every result.
</Update>

<Update label="May 19, 2026" description="Structured search DSL" rss={{ title: "Search DSL" }}>
  **Search DSL**

  * **Field-level targeting**: a structured intent DSL targets names, employers, schools, and locations instead of one free-text string.

  See [Search Intent →](/api/search/search-intent)
</Update>

<Update label="May 18, 2026" description="Deep person search" rss={{ title: "Deep Person Search" }}>
  **Deep Person Search**

  * **Seed a person, get a profile**: the first deep-search endpoints launched: Orbit builds a full public profile from a seed.
</Update>

<Update label="May 8, 2026" description="Docs launch" rss={{ title: "Docs Launch" }}>
  **Docs Launch**

  * **Day one**: the developer documentation went live with authentication, quickstart, and the first API references.

  See [Quickstart →](/quickstart)
</Update>