Skip to main content
Follow API updates in your own tools by subscribing to the RSS feed. 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.

​
October 2026

​
Faces that look alike are listed as sources
Face Search
  • Results are the picked face: each result is a person that pages of the picked face show.
  • Lookalike faces: pages that show a face that looks alike stay in discovered_sources with face_match.kept false, ready to list as other faces.
See Face Search →
​
Every source a search finds, and the pages of the picked face
Sources as the search finds them
  • A complete source list: discovered_sources lists every page a Candidate Discovery search has found, in the order the search first found each one, up to 200 pages. A page stays listed through later polls and after the search ends.
  • Sooner: pages from handle, email, and web lookups join the list while the search runs.
  • Assigned pages stay listed: a page in a result’s candidate_sources is also in discovered_sources.
Face Search
  • Pages of the picked face: face_match.kept says whether the search counts a page as a page of the picked face. Pages with kept false show another face that looks alike.
See Face Search →
​
Find the people a photo could show
Face Search
  • Faces in a photo: POST /v3/faces/detect stores a photo privately and returns every face in it, each with its bbox.
  • Known profiles first: POST /v3/faces/index-search returns the Orbit profiles that already show the picked face, for free.
  • Search by face: send the picked face as signals.face_source on POST /v3/search. Orbit searches the web for the face and returns a list of possible people, best match first, up to candidate_discovery_limit (default 10).
  • Confidence per person: each result’s confidence, confidence_level, and confidence_status include how strongly the face matches that person. Source pages that show the face carry face_match.
  • Names help: a typed name or other signal ranks matching people higher. The face decides who is in the list.
  • Pricing: 100 credits per face search, charged once Orbit searches the web for the face, plus the normal profile rate for each person returned. Detecting faces and searching the face index are free.
See Face Search →

​
September 2026

​
Search results delivered by webhook
Search Webhooks
  • Results arrive as they are built: start a search with "webhooks": true and each result reaches your endpoint as a search.profile.updated delivery every time it advances a generation step, carrying that person’s whole profile in the shape a profile read returns. search.completed closes the search out once.
  • The same rows a poll returns: the result in a delivery is the row GET /v3/search/{search_id} returns at that moment, so a handler written against the poll response reads a delivery unchanged. Deliveries are free and leave the search’s price alone.
  • Per search, on request: a search reaches the feed when your organization has an endpoint subscribed to the search event types and that search asked for them.
See Push search results → and Webhook events →
​
Face match scores on profile images
Face Match Scores
  • See why an image is on a profile: every image in the images section of a profile now carries faceMatch and faceMatchScore when the face model compared it against the profile’s anchor face. The score is a cosine similarity from 0 to 1.
  • Set your own bar: Orbit sets faceMatch to true above 0.3. With the score in hand you can hold photos to a stricter bar before you show them.
  • Both fields are reserved for images the face model compared, so an image Orbit kept on other evidence, such as a photo from an account the person owns, arrives with its sources alone.
See Read a profile →
​
Section changes in watcher runs and webhooks
Section Change Notifications
  • Changed sections are reported: when a watcher run changes a profile section — a new job, a new accomplishment, an updated net-worth range — the run’s changes and the profile.updated delivery carry a section_updated entry naming the section and its items_added and items_removed. updatedSections on the delivery lists those sections beside events_timeline.
  • Updates are reported where they appear: a job update that adds a job and a timeline event produces one section_updated change and one event. New information — a recent or upcoming event, a changed section, a new source, or new social activity — is what triggers a delivery and the update premium.
See Watchers → and Webhook events →
​
Test webhook deliveries
Test Webhook Deliveries
  • Trigger a delivery on demand: POST /v3/webhooks/{webhook_id}/test signs and posts one event to your endpoint right away, so you can build and verify your handler without waiting for a watcher run.
  • The body is your most recent event of that type when you have one and an example payload otherwise; the envelope carries "test": true and an evt_test_ event ID.
  • Test deliveries are free, are attempted once with no retries, are kept out of your delivery history, and never count toward the failures that disable an endpoint. The route is rate limited more tightly than the rest of the API.
See Send a test delivery →

​
September 2026

​
Population searches
Population Searches
  • Search a whole company or school: POST /v3/search/populations returns everyone at a company or everyone who attended a school, at the profile_depth you choose. People are added to the results as the search finds them, and the snapshot’s population block reports its status.
  • Priced before it starts: POST /v3/search/populations/quote returns one total in credits, and the search reserves that amount.
  • Query intent on the snapshot: query_intent reports the organizations and schools a plain-English query names, and whether it names a person.
See Search a population → and Credits →.

​
August 2026

​
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 → and Webhook events →. Read the launch post: Introducing Watchers →
​
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 →
​
Image 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 →
​
Per-item 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 →
​
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 →
​
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 →

​
July 2026

​
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 →
​
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 profile read response now follows a complete, stable contract.
See Read Profile →
​
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 →
​
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 →
​
Search and Enrich APIs
Search and Enrich
  • One surface, two jobs: the API 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 current endpoint contract by following our migration guide.
See Migration Guide →
​
Progressive results
Progressive Results
  • Render as it builds: deep searches return partial results while generation continues.
​
Search workflow endpoints
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 Search API.
​
Regeneration contract
Regeneration Contract
  • Explicit semantics: full regenerations rebuild from a clean slate, and partial runs continue from existing content.
See Enrich Profile →
​
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.
​
Higher rate limits
Higher Rate Limits
  • More headroom: rate limits increased across Search and profile reads.
See Rate Limits →

​
June 2026

​
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.
​
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 →
​
Clear failure reporting
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.
​
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 →
​
One canonical profile ID
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.
​
Poll-only status contract
Poll-Only Status Contract
  • Polling 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.
​
Durable profile aliases
Durable Profile Aliases
  • IDs that last: when profiles merge, old IDs become aliases that keep resolving to the canonical profile.
​
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.
​
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.

​
May 2026

​
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.
​
Structured intent
Structured Intent
  • Semantic clauses: deep searches accept structured intent with semantic clauses.
  • One search endpoint: Smart Search consolidated onto a single endpoint.
​
Seeded searches
Seeded Searches
  • Email and LinkedIn seeds: searches accept identity seeds for higher precision.
  • Why it matched: includeMatchReason explains every result.
​
Structured 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 →
​
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.
​
Docs launch
Docs Launch
  • Day one: the developer documentation went live with authentication, quickstart, and the first API references.
See Quickstart →