Skip to main content
The Osintly API lets you create searches, stream progress in real time, retrieve leak datasets, access Radar breach intelligence, and check usage limits.

REST + SSE

Start searches with REST and stream execution updates through Server-Sent Events.

Bearer auth

Authenticate requests with a bearer token in the Authorization header.

Typed schema

Endpoint contracts are defined in OpenAPI and rendered in the Endpoints section.

Base URLs

  • Production: https://api.osint.ly

API surface

AreaEndpoints
SystemGET /health
AuthGET /
UsageGET /usage
Radar (Free plan)GET /radar/breaches, GET /radar/breaches/{name}
SearchPOST /search, POST /search/module/once, POST /search/delete, GET /search/{id}, GET /search/{id}/results, GET /search/{id}/byok, GET /search/{id}/stream, GET /search/{id}/results/leaks, GET /search/{id}/results/leaks/{source}
Webhook deliveryConfigured in POST /search with delivery.webhook
Radar is free to use, but not anonymous: you still need an Osintly account and a free API key.

Plans and capacity

  • API plans and Osintly app plans are separate products: you can have both, either one, or neither.
  • If you only have an API plan, you can use API endpoints but you do not automatically get access to the Osintly app plan features.
  • Free API plan currently provides API key access and unlimited Radar endpoint access (GET /radar/breaches, GET /radar/breaches/{name}).
  • Free API plan may evolve over time.
  • Search API capacity (RPM and concurrency) depends on your active API plan and is enforced at runtime.
  • If capacity is exhausted, you may receive 429 RATE_LIMIT_EXCEEDED/RATE_LIMIT_RPM_EXCEEDED or 409 MAX_CONCURRENCY_EXCEEDED.
Read full details in API Plans & Capacity.

BYOK providers

Osintly API can also act as a hub for supported external providers through BYOK (Bring Your Own Key). Instead of integrating each provider separately, you can send your provider credentials once in the search request and retrieve their results through the same Osintly search lifecycle, streaming flow, and normalized result endpoints. Currently documented BYOK providers include: With BYOK, Osintly does not become the source of truth for those providers. Their reliability, uptime, response quality, billing rules, rate limits, and result freshness remain dependent on the external services themselves. Osintly integrates their APIs as faithfully as possible based on their public documentation and observed behavior. We make a best effort to keep BYOK integrations aligned with provider documentation. When providers change their request or response formats, we work to keep the Osintly BYOK layer up to date, but external changes may temporarily affect behavior until the integration is refreshed.
BYOK is designed as an API multiplier: it lets you orchestrate first-party Osintly search capabilities and third-party providers from a single entry point.

Why use Osintly API with BYOK instead of calling providers directly?

  • One integration surface: use one authentication model, one search payload pattern, and one retrieval flow instead of maintaining separate clients for each provider.
  • Unified orchestration: run first-party Osintly modules, leaks, account features, and BYOK providers inside the same search execution.
  • Real-time streaming: consume progress through one SSE stream instead of building separate async handling for each provider.
  • Normalized outputs: retrieve provider results in a shape that is easier to combine with the rest of your Osintly workflow.
  • Shared retrieval model: use the same search id to access status, results, BYOK provider details, leak pages, and webhooks.
  • Less glue code: avoid rebuilding request validation, job coordination, persistence, and response normalization for every provider.
  • Easier product integration: if your application already uses Osintly for search, BYOK lets you extend coverage without creating a second integration architecture.
Direct provider integrations can still make sense if you only need a single provider and want full control over every low-level request detail. BYOK is most useful when you want Osintly to remain the operational hub for your OSINT pipeline.

Next steps

  1. Read Authentication
  2. Run your first request in Quick Start
  3. Review Search Retention for cleanup guidance
  4. Read the SSE Reference
  5. Explore endpoint schemas in the Endpoints group