Every source, behind one authenticated API.
Ask for a capability rather than a provider. The platform decides which upstream answers, and your integration never learns which one did — so when sources change, your code does not.
Ask for a capability, not a provider.
The platform is a parameter, never part of the capability id. You call social.posts.search with platform: "instagram" — not a provider-specific endpoint. So adding a platform adds no capability, breaks no client, and needs no change on your side.
- social.posts.search
- Search posts across a platform.
- social.profile.lookup
- Resolve a profile from a handle or URL.
- social.profile.posts
- What a profile has published.
- social.profile.connections
- Who a profile is connected to.
- social.group.search
- Find groups and channels.
- social.group.members
- Who is in a group.
- social.post.comments
- Comments on a post.
- social.post.engagement
- Who engaged with a post.
- social.media.details
- Details of a photo, video or other media.
- identity.username.search
- Find accounts by username across sites.
- identity.email.lookup
- What is known about an email address.
- identity.phone.lookup
- What is known about a phone number.
- identity.domain.emails
- Email addresses and patterns at a domain.
- identity.national_id.lookup
- Resolve a national identity number.
- corporate.company.profile
- A registered company and its filings.
- corporate.company.officers
- Who holds office at a company.
- corporate.officer.appointments
- Everywhere an officer holds office.
- corporate.address.entities
- What is registered at an address.
- web.domain.details
- Registration, records and history.
- web.ip.details
- Geolocation, ASN and exposure.
- web.location.details
- What is at a location.
- dev.repository.details
- A repository and its contributors.
Announced but not yet routed, and marked as such in the live catalogue: crypto.address.lookup, crypto.transaction.lookup and web.darkweb.search. They are published so you can plan against them, not so you can call them today.
What can I do with the thing I am holding?
Sixty-four canonical entity kinds, and a genuine reverse index built from what every capability accepts. That is what lets a consumer walk a graph — take a result, ask what it can be used for, and continue — rather than only re-running a search it already knew it wanted.
Reliability is a labelled promise, not a hidden risk.
Twenty source adapters in three tiers. Experimental sources are off by default, enabled per organisation, and labelled in every response that used one — so you always know how much weight an answer carries.
Async by default, and documented from the running code.
The things people ask before a briefing.
Which upstream source answers my call?
You are not told, by design. You request a capability and the platform routes it. Sources change, and an integration written against a specific one would break when they do.
How do I find out what I can do with a result?
GET /v1/entity-types/{kind}/capabilities returns every capability that accepts that kind as input. It is a real reverse index over the catalogue, which is what lets you walk a graph rather than only repeat a search.
How is usage metered?
Two meters. Plan quota counts requests — the Standard plan allows 500 a day and 10,000 a month — and provider credits are counted separately per UTC day, because metering only one of them breaks either the licence or the pricing.
Is there an OpenAPI spec?
Yes, generated at boot from the live routes, so it cannot drift from the API. A Postman collection and environment are generated from the same catalogue.
Read the docs, then take a key.
The full API reference, an in-browser explorer and a downloadable Postman collection are on the portal. Sign up, get your organisation approved, and issue your own keys.