Bright Data SERP API

The Bright Data SERP API provides real-time access to structured search engine results pages from seven major search engines, including Google, Bing, and Yandex. Results are returned in JSON or HTML and support geo-targeting down to the city level. Pricing applies only to successful requests, making it predictable for production workloads.

General
Developer	Bright Data
Type	Search Engine Results API
Engines Supported	7 (Google, Bing, Yandex, and others)
Countries	195
Documentation	docs.brightdata.com/serp
Product Page	brightdata.com/products/serp-api

Core Features

7 search engines: Google, Bing, Yandex, and four additional engines covered with a unified API interface.
195 country coverage: geo-target results to any country, with city-level options for Google.
JSON and HTML output: receive results in structured JSON for automated parsing or raw HTML for custom processing.
Pay-per-success pricing: no charge for failed or blocked requests, only successful result deliveries.
Response time under 5 seconds: consistent latency targets for production use.
Real user results: results reflect what real users see in a given location, not cached or sanitised snapshots.

Supported Search Types

Organic search results
Google Shopping results
Google Maps listings
Google News results
Image search results
Autocomplete suggestions

Tools and Resources

Python SDK: query search engines programmatically from Python.
JavaScript SDK: SERP queries from Node.js, Bun, or Deno environments.
Google Search API page: Google-specific configuration and parameters.
API Reference: full request/response schema documentation.

Ecosystem and Integrations

Works with the Bright Data MCP Server to expose search capabilities to AI agents and coding assistants.
Output integrates into RAG pipelines, market intelligence dashboards, and SEO monitoring tools.
Can be combined with the Web Scraper API to first retrieve search results and then scrape the linked pages.

Start querying search engines at brightdata.com/products/serp-api or read the API documentation for parameter reference and example requests.

HandSpeak

SignBridge is a real-time AI-powered sign language interpretation system designed to make communication more accessible between sign language users and people who do not understand sign language. Using a camera, the system detects hand and body movements, analyzes gesture sequences, and converts recognized signs into natural-language text and speech. The project will leverage AMD GPU acceleration to improve real-time computer vision and AI inference performance, allowing the system to process video with low latency. Beyond individual signs, SignBridge aims to recognize sequences of gestures and reconstruct meaningful phrases, making communication more natural. The project combines accessibility, computer vision, AI, and high-performance AMD computing to create a practical assistive technology solution.

ELARA — Your Voice Agent

ELARA is a secure, real-time voice friend built for the AssemblyAI Voice Agent Hackathon. You speak naturally; ELARA listens, understands, and replies out loud — no typing required. At the core is AssemblyAI’s real-time streaming speech-to-text (universal-3-5-pro). The browser never sees the long-lived API key: a server route mints a short-lived, single-use token, opens a WebSocket, and streams PCM16 audio frames directly from the microphone. Partial transcripts appear while you speak. Sessions are cleanly terminated so billing stays accurate. When a question needs fresh facts (weather, news, prices, scores), a deterministic router sends the turn to live web search via Bright Data SERP. The model answers only from real results. If search fails, ELARA says so instead of inventing current information. Everyday chat (jokes, feelings, opinions) is answered from memory without a lookup. The full pipeline is a locked 5-stage brain running entirely on the server: input safety (Groq), optional fast assist (Gemini), main response (Groq), reorganize + emotion (Groq/Ollama), and output safety (Groq). Keys never leave the server. Audio is never stored by ELARA. Privacy and safety are built in: Supabase Auth with Row Level Security, anonymous + Google + email sign-in, layered safety gates, and clear disclosure that Bangla currently uses the browser’s speech recognition as a fallback. ELARA is designed for hands-busy users, accessibility needs, and anyone who wants a voice agent that is fast, honest, and private. Built with Next.js, Supabase, AssemblyAI, Groq, Google AI, and Bright Data.

Fresno LUX: A Living City

Fresno LUX is a prototype for a living intelligence layer across an entire city. Fresno already contains enormous amounts of intelligence: residents know where problems exist, nonprofits know where help is needed, businesses know where opportunities exist, educators understand gaps in learning, researchers generate knowledge, and government maintains critical infrastructure and data. The problem is that much of this intelligence is fragmented across disconnected systems. Fresno LUX connects those pieces. The platform creates a shared city graph where people, organizations, resources, needs, projects, observations, experiments, and outcomes become connected nodes. Instead of simply collecting data, LUX continuously asks: What is happening? What do we know? What is missing? What can we test? What changed? A community problem can become an observable signal. That signal can become an experiment. The experiment produces evidence. Evidence changes the system's understanding. That updated understanding informs the next action. Observe → Connect → Understand → Act → Measure → Learn → Converge. The goal is to move Fresno from disconnected information toward collective intelligence—a system where knowledge can travel across boundaries and successful solutions can be discovered, tested, measured, and replicated. LUX is designed to make the invisible connections visible: the relationship between a neighborhood and its resources, between a student and educational opportunity, between a business and workforce capacity, between environmental conditions and community health, and between an idea and measurable real-world impact. This hackathon prototype demonstrates the beginning of a Living Fresno Graph: a city that can observe itself, learn from evidence, and coordinate toward better outcomes.

Rehearsal - Research. Practice. Get Hired.

The problem Candidates rehearse “tell me about yourself” and “greatest weakness,” then walk into a room where the conversation is about this posting, this stack, and what the company shipped last month. The gap between generic prep and a real interview is where people lose. Those specifics are public — the posting, the company page, the news — but almost nobody works through them systematically the night before. What we built Rehearsal is a three-tab workspace: Research · Rehearse · Relive. 1. Research — Paste a job link. Three live scrapes land as cards (job, company, news) with source domain and timestamp. A prep brief and optional resume-based fit match sit inside the same dossier. 2. Rehearse — Choose Voice or Text. An interviewer (named, role-framed) asks questions grounded in that dossier — e.g. Deltek Playwright/LLM-as-judge QA, or Dodo Payments developer onboarding — not recycled bank questions. Source labels show where each question came from. 3. Relive — Answers are scored with missed points and model answers so practice produces a verdict, not just a feeling. Why it is different Every question is meant to be traceable to scraped evidence. A generic tool asks about test pyramids; Rehearsal asks how you would build an LLM-as-judge pipeline because that sentence is in the posting, and it can show you the line. Design Institutional dossier aesthetic — paper and ink, mono for facts, signal red only when the mic is live. Not a chat UI. Not a SaaS dashboard. A file being assembled on a candidate. Scope One job at a time, night-before practice: research → rehearse → review. Not job search, not mass apply, not a career LMS. Demo / status End-to-end research and interview paths run against live services. Demo film uses product stills + music-led cards (screenshot cut under time). Live product: https://rehearsal.nryn.dev Made by Narayan SS · nryn.dev

Kitna? Point your camera, know its worth

The problem. Nearly everyone in India has things they no longer use, and two questions stop the sale. What is it actually worth right now, and where do I sell it for the best return? Listings go stale, condition changes everything, and prices are scattered across Cashify, Quikr, Facebook Marketplace and WhatsApp groups with no way to compare them. Who it's for. People in India decluttering or upgrading, who know what they own but have no idea what it is worth, how to price it, or how to defend that price to a buyer. What Kitna? does. Point your camera at an item. On-device detection frames it in the live viewfinder and crops it, then a cloud vision model identifies the item and grades its condition, naming the specific wear it can see in your photo. Bright Data's SERP API pulls live listings from Indian marketplaces, and those real comps set both the resale range and its confidence band. You get a recommended sales channel, a ready-to-paste marketplace listing, and a Mol-bhaav haggling script with your asking price, your walk-away floor, and two Hindi-English counter-lines. Every number traces to evidence. The condition grade cites what the model actually saw. The price cites listings you can click. When no real comps come back, the app says so plainly and labels the figure an estimate. It never presents a price as live unless real listings back it. How native.builder was used. The Product Architect wrote the PRD from a plain-language spec. The Builder agent generated the Vite, React and TypeScript application, the design system, the camera capture hook and every screen, provisioned Supabase, and deployed the Edge Functions that keep all API keys server-side. The QA agent caught two dead-end bugs during live browser testing. External services. AI/ML API for vision with structured JSON output, Bright Data SERP API for live India comps, Speechmatics for voice, Supabase Edge Functions for secrets and runtime, and TensorFlow.js for on-device detection.

OnRecord - verificarion for spoken claims

Problem statement: In founder pitches, vendor demos, and partner calls, people make confident, specific, checkable claims — market sizes, competitor pricing, "we're the only ones who do X." Almost none of it is verified before a decision is made. Verification is manual and slow: listen back, work out which claims are checkable, open twenty tabs, then try to remember whether this person said something different eight months ago. The evidence is public. The bottleneck is that nobody can traverse it fast enough. Target user: Analysts, angel investors, and operators evaluating founder pitches, vendor demos, and partner calls. Adjacent: journalists and podcast producers doing pre-publication verification, enterprise vendor diligence, and comms teams reviewing their own executives. How native.builder was used: Built end to end in native.builder. Product Architect scoped the PRD, data model, and Edge Function architecture before any code was written — it surfaced four design problems in my brief, including an ambiguity about which Bright Data product the pipeline needed. Task Planner produced the dependency graph. Builder agent generated the React application, Supabase schema, and Edge Functions across ten incremental prompts, and diagnosed a stale Vite dependency cache without intervention. The UI, data model, verdict logic, and contradiction detection are complete and demonstrated on fixture data. The Speechmatics transcription Edge Function is built and deployed; the multipart submission format is still being resolved. Tools: native.builder, Supabase (Postgres, Storage, Edge Functions, Realtime), Speechmatics Batch API, Bright Data (SERP API, Web Unlocker), AI/ML API, React, Vite, Tailwind.