Connect your AI agent to your developer data.

get-adoption-score

Returns your living adoption score: a 0 to 100 synthesis of the three layers Built for Devs measures. Agent readiness comes from the latest agent evaluation run per ICP, human evaluation from the latest published findings report, and live signal from real developer sessions hitting your TTV definition. The response shows exactly what the score stands on: per layer, whether data was available, the layer sub-score, how fresh the reading is, and the supporting details behind it. It also includes the movement history, so you can see how the score has changed over time and what triggered each recompute. Pass history_limit to control how many past readings come back (default 12, max 52). Use this as the single number to track, and drill into the layers when you want to know why it moved.

get-agent-evaluation

Returns agent evaluation runs: automated sessions where an AI agent attempts your onboarding the way a real developer would, once per ICP. By default you get the latest finished run per ICP, which includes both completed runs and runs that ended Blocked because the agent hit a wall it could not cross on its own (a CAPTCHA, email verification, or a payment gate); failed and unfinished runs are excluded. Each run exposes its status (complete or blocked), whether the agent reached time to value and how long it took, every point where it got blocked and what a human would have needed to do, time spent per journey stage, whether your CLI and docs were accessible to an agent, the agent-friendliness score, and a narrative summary of what the agent could and could not do. Each run also returns facets: a per-resource agent-readiness checklist, judged in the ICP's persona, marking each of docs, quickstart, cli, sdk, apiReference, codeExamples, apiKey, and mcp as accessible, not_found, not_applicable, or null when the agent did not assess it. Alongside the narrative you get friction_items and improvement_items — severity-ranked lists (high, medium, low) of exactly where the agent hit friction and what it would change — and what_was_missing, the persona-relative gaps: the resources this developer needed and could not find. Runs also return code_executions: the exact terminal transcript the agent ran in its sandbox — the commands it issued with their stdout, stderr, and exit codes, already redacted and truncated — so your own AI agent can see precisely what was executed. Pass icp_id to focus on one ICP, or agent_evaluation_id for a specific run regardless of status. Use this to answer the question your customers are already asking: can an AI coding assistant actually use this product?

get-recommendations

Returns the recommendations Built for Devs generates from your data, each with cited evidence: which layer it came from (agent readiness, human evaluation, or live signal), the specific data sources behind it, and the expected impact. Nothing here is generic advice; every recommendation traces back to something observed in your product. Each one carries a deliverable_type (content_pr, strategy_doc, or advisory), a scope describing exactly what a paid result would deliver, and quote_cents — the engine-quoted price for a content_pr result, the flat price for a strategy_doc, and null only for advisory recommendations you can act on yourself. Once a result is purchased, the recommendation includes its result status (queued, in_progress, or delivered) and the delivered artifact URL. Completed recommendations include the outcome: TTV before, TTV after, the delta, and whether the change moved the needle. Filter with status (active, completed, dismissed, or all; default active); results come back newest first alongside per-status counts. Use this to pull your open DX backlog straight into your planning workflow, or to report on which past changes actually paid off.

get-product-profile

Returns the product profile detected during onboarding enrichment: your docs URL, pricing model, product category, and positioning summary, along with the evidence behind each detection. When you have confirmed the profile, is_confirmed is true and any corrections you made are included. This is the context agent evaluations and recommendations are grounded in, so it is useful for verifying that Built for Devs understands your product the way you do.

list-icps

Lists the Ideal Customer Profiles defined for your product. Each ICP describes a developer persona the weekly agent evaluation runs as: the matching criteria (role, seniority, languages, frameworks) and the persona the agent embodies during its run. Each entry includes the latest finished agent evaluation for that ICP (completed or blocked), so your agent can chain straight into get-agent-evaluation for the full report. Use this to see who your product is being evaluated as, and to compare agent-readiness across the audiences you care about.

suggest-icp

Suggests the next-best, complementary audience for your product: a distinct developer persona you are not already targeting, grounded in your product profile and the ICPs you already have. Deciding who else to target is one of the hardest calls a developer-tool team makes, and this puts an opinionated starting point in front of you. Returns the suggestion as data — a label, the evaluation persona (title and narrative), the full taxonomy criteria (role, seniority, languages, frameworks, stack, industries, company and team size, buying influence, and more), and a short rationale for why it broadens your coverage — alongside your current plan slot usage (used and remaining) so your agent knows whether a slot is even free. This tool is advisory and read-only: it does not create the ICP. Review the suggestion, tweak it, and create it from the Manage ICPs page in your dashboard — the same one-click flow the Suggest ICP button uses there.

get-error-groups

Returns JavaScript errors from real developer sessions, grouped by normalized error message. Each group includes occurrence and session counts, first and last seen timestamps, the top pages where the error fires, and a drop-off correlation: the share of affected sessions that showed no further activity after first hitting the error. That correlation is the difference between an error that is noise and an error that is costing you developers. Bots, internal traffic, and agent evaluation sessions are excluded. Pass days (1 to 90, default 30) to control the window; results are paginated. Use this to prioritize which errors to fix first based on real impact, not raw counts.

get-developer-funnel

Returns your complete developer journey funnel from the most recent snapshot. Agent evaluation sessions, bots, and internal traffic are excluded, so the numbers reflect real developers only. Includes session counts, drop-off rates, and average time spent at each of the seven stages: Discovery, First Impression, Onboarding Setup, First Value, Adoption, Expansion, and Advocacy. Also returns a list of all identified developers who have been observed in your product, with their current journey stage and last seen timestamp. Use this as the starting point to understand the overall health of your developer onboarding: where developers are getting stuck, how long the critical path to first value actually takes, and which stage has the worst drop-off.

get-friction-signals

Returns aggregated behavioral friction signals from the last 30 days, grouped by type and page. Built for Devs tracks four categories of developer frustration that most analytics tools miss entirely: rage clicks (rapid repeated clicks in the same spot, indicating broken or confusing UI), copy events (what developers are copying and from which pages, with a 40-character preview; when a key or token is detected the preview is suppressed and replaced with a key_type label like "API key" or "Bearer token" so you know what they found without seeing the value), JavaScript errors (uncaught exceptions and unhandled promise rejections with filename and line number), and scroll depth patterns (how far developers scroll on key pages before leaving). Use this to surface exactly where your developer experience is breaking down, which pages are causing the most frustration, and what content developers are extracting for later use.

get-ttv-trend

Returns time to value (TTV) trend data for your product, broken down by month, showing whether developer onboarding is getting faster or slower over time. TTV measures the median time in seconds from a developer's first session to the moment they reach your defined "first value" event, the moment they've successfully built something meaningful with your product. Pass months (1–12) to control the lookback window; default is 6 months. Each data point includes the month, the median TTV in seconds, the number of developers who reached first value that month, and a comparison delta versus the prior period. Use this to measure the long-term impact of developer experience improvements. If you rewrote your getting started guide, this is where you'd see whether it worked.

get-developer-session

Returns a complete behavioral profile for a specific developer or a single session. Pass a developer_id (the identifier you set via BFD.identify()) to retrieve every session that developer has had across your product: their full journey, every page visited, time spent per page, and any friction events encountered. Pass a session_id to drill into a single session. Each session includes an AI-generated narrative summary of what the developer was doing and where they got stuck, a chronological list of pages visited with timestamps, a breakdown of event types that occurred, and details on any rage clicks or JavaScript errors. Single-session responses carry the agent/human dimension: is_agent_session is true when the session came from an agent evaluation run rather than a real developer. Use this when a specific developer reports a problem, when you want to understand why someone churned, or to build an accurate mental model of what onboarding actually feels like in practice.

get-evaluation-report

Returns the published findings report from a completed evaluation project. Built for Devs evaluation projects are live sessions where real developers attempt to build something with your product while their screen is recorded. After transcription and AI analysis, a structured findings report is generated. This tool exposes that report: the executive summary, a scored rubric across key developer experience dimensions, critical blocking issues, quick wins that would have the highest impact, specific things developers praised, and the full narrative report. Pass a project_id from your Evaluations page. Recording files and raw transcripts are never exposed. Use this to bring your evaluation findings directly into your planning workflow: have your AI agent summarize findings into Linear issues, prioritize them against your roadmap, or write a post-mortem.

query-events

Raw, paginated access to your tracking events with full filtering. Supports filtering by date range (max 90 days), event type (pageview, click, scroll_depth, copy, rage_click, js_error, form_focus, form_submit, return_visit, external_link, time_on_page), page URL (partial match), session ID, or developer ID. Returns up to 200 results per page. Bots and internal traffic are always excluded. Agent evaluation sessions are excluded by default; pass include_agent_sessions to include them, and use the agent_evaluation_id field on each event to tell agent traffic from human traffic. Each event includes the URL it occurred on, its type, a timestamp, the session ID, the developer's identifier (if identified), and a metadata field whose contents vary by event type. See the event reference on this page. Use this when you have a specific question the higher-level tools don't answer: "show me every form_submit event on the quickstart page in the last two weeks," "what pages did this session visit before they hit a JS error," or "how many developers clicked this specific button."