Skip to main content
A Brand lookup for a domain Context.dev hasn’t seen before triggers a full crawl of the website and socials, which typically takes around 7s, up to a minute at p99, with a hard platform cap of 5 minutes. Once cached, the same lookup returns in under a second, and about 60% of all Brand API calls already hit that warm cache (full breakdown in the latency table below). Prefetching warms the cache ahead of time. Call a prefetch endpoint as soon as you know the domain or email, and the user-facing /brand/retrieve lands on a warm cache:
  • /brand/prefetch if you have a domain.
  • /brand/prefetch-by-email if you have a work email.
The canonical case is a signup or onboarding form: fire a prefetch the moment the email field validates, and by the time the user submits, /brand/retrieve returns instantly. 0 Credits on both. No rate limit. Subscriber-only. 
# 1. As soon as the email field validates, fire a prefetch.
curl -X POST https://api.context.dev/v1/brand/prefetch-by-email \
  -H "Authorization: Bearer $CONTEXT_DEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]"}'

# 2. On submit, the real call hits a warm cache.
curl -G https://api.context.dev/v1/brand/retrieve \
  -H "Authorization: Bearer $CONTEXT_DEV_API_KEY" \
  --data-urlencode "domain=acme.com"

​
How the cache works

  • Cache TTL is up to 3 months. After that, the next call triggers a refresh in the background.
  • The cache is shared across the account. A prefetch from a backend job warms the cache for a user-facing call seconds later.
  • Prefetch is fire-and-forget. Both endpoints return immediately after queuing the work. You do not wait for the prefetch before calling /brand/retrieve.
  • Prefetch by email skips known free/disposable providers. Calls against gmail.com, yahoo.com, outlook.com, and the 10,000+ disposable services return an error you can safely ignore.

​
Latency

Patternp50p90p99
Cold /brand/retrieve (no prefetch)7s18s~1 min
Cached /brand/retrieve (after prefetch or prior hit)<1s<1s<1s
Every second of prefetch lead time turns a multi-second (sometimes minute-long) cold wait into a sub-second user-facing call.

​
What prefetch does not do

  • It does not speed up scraping endpoints. /web/scrape/*, /web/crawl, /web/screenshot, and /brand/ai/* are not affected by the brand cache. Each call fetches the target URL.
  • It does not preempt rate limits. Prefetch itself is rate-limit-free, but the eventual /brand/retrieve call still counts against your plan’s per-minute rate limit.
  • It does not return brand data. The endpoint queues the work and returns { status, message, domain }. To read the brand, call /brand/retrieve separately.

Rate limits

How the per-plan per-minute limits interact with cached and prefetched calls.

Best practices

Where prefetching fits in the broader integration pattern.

Troubleshooting

Cold-hit timeouts and how to handle them.

Get brand data

The endpoint prefetching warms.