DocumentationAPI Reference
    Auth and API keys

    Auth and API keys

    Desearch authenticates REST calls with an API key. Create the key in Desearch Console, store it as an environment variable, and send it on every request.

    1. Create a key

    1. Open Desearch Console.
    2. Go to API Keys.
    3. Create a key and copy it once. Store it as DESEARCH_API_KEY on your server.

    2. Send the header

    Preferred (raw key):

    bash
    curl --request POST 'https://api.desearch.ai/desearch/ai/search' \ --header "Authorization: $DESEARCH_API_KEY" \ --header 'Content-Type: application/json' \ --data '{"prompt":"latest AI search API notes","tools":["web"],"count":10}'

    OpenAPI names this scheme ApiKeyAuth: API key in the Authorization header.

    Auth errors

    Desearch API keys start with dt_ or dsr_. A malformed or unrecognized Authorization value, such as a placeholder or a truncated key, can be handled as a Console session token instead of an API key. Console session tokens only work from Desearch Console, so that request can be rejected with 403 by token or origin checks.

    Observed responses for GET /twitter/trends?woeid=1&count=30, sent with no Origin header and deliberately invalid values:

    Authorization sentStatusBody
    No header401{"detail":"Unauthorized"}
    dt_invalid_docs_check_0000401{"error":"Invalid API key"}
    dsr_invalid_docs_check_0000401{"error":"Invalid API key"}
    YOUR_API_KEY (unreplaced placeholder)403{"detail":"Forbidden"}
    fake-key-for-leak-test403{"detail":"Forbidden"}

    Invalid values do not all get the same status: some return 401 and some return 403, as the table shows. If you get a 401 or 403 from a server-side call, check that the header holds the full API key from Console, copied exactly. Do not try to fix it by adding headers; external callers should always use an API key.

    These responses were checked on 2026-10-04 against GET /twitter/trends only. Other endpoints were not each tested.

    3. Rotate and revoke

    • Rotate keys when someone leaves the team or a key may have leaked.
    • Revoke old keys in Console after the new key is deployed.
    • Prefer separate keys per environment (dev / staging / prod).

    4. What not to do

    • Do not put API keys in frontend bundles, mobile apps, or public repos.
    • Do not paste production keys into screenshots, tickets, or chat.
    • Do not treat Desearch 2.0 proposed APIs as live.

    Agents vs Humans

    AudienceWhat to do
    HumansCreate and rotate keys in Console. Set environment variables on your host.
    AgentsRead DESEARCH_API_KEY from the environment. Never hard-code a key.