API Report Card · Workflow & CRM · Methodology v1.1
Follow Up Boss
NOTE: This grade is produced by an AI analysis run against the same published grading file, which you can download and check here. The scope is deliberately narrow: API and data access. It is not Peter Lohmann's opinion of Follow Up Boss as a software platform, and it says nothing about Follow Up Boss's features, reliability, interface, support, or standing in the industry.
Where the points came from.
Five categories, each worth a fixed share of the 100 points. A category earns the fraction of its checks it passes, times its maximum.
Functional Coverage
Design & Reliability
Access Control
Docs & AI-Ready
Access & Cost
Letter grades are absolute, never curved.
The same numeric bands apply to every platform. Nothing here is scored relative to the rest of the board.
What this means for you.
One paragraph per category, in plain language.
1 · Functional Coverage
Nearly everything a CRM holds is readable and writable through the API: contacts, deals, pipelines, stages and custom fields, including deletes and stage moves. You can drop leads in, start or pause an action plan or automation for a contact, and move deals between stages. Two limits shape what you can build. The automation rules themselves can only be built and edited in the Follow Up Boss screens, and the newer Automations 2.0 endpoints answer only to a registered system, so the operator's own key got a 403 until one is registered. There is also no event when an automation starts or finishes, so you watch for its side effects or poll.
See technical details2 · Design & Reliability
The API behaves like a normal modern REST API: clean JSON, cursor paging verified live, rate-limit headers on every response with a documented 429 and Retry-After, and a real status page with an API component and incident history, so an AI agent or a no-code tool will not be surprised by its shape. The rough edges are on the operations side. Errors come back as messages rather than codes, bad query parameters are silently ignored instead of rejected, only contacts can be synced by changed-since, nothing protects you from double-creating notes or tasks on a retry, and there is no documented way to detect that someone else edited a contact between your read and your write.
See technical details3 · Access Control
You can mint a separate, named key for every tool or agent and kill any one of them instantly, and Follow Up Boss documents a separate trial or dev account to test in. What you cannot do is hand an agent a read-only or narrowly scoped key: every key carries the full rights of the user who made it, so a key made by the owner can do anything the owner can, including deleting contacts. Give an AI agent a key from a low-privilege user rather than the owner.
See technical details4 · Docs & AI-Ready
An AI coding tool can pull the whole reference as Markdown from one index file and read every endpoint's parameters from the OpenAPI file, which is better than most vendors in this space. Expect to fill gaps yourself: the OpenAPI file gives no typed responses for contacts or deals and needs path fixes before you generate a client from it, many write endpoints show no example response, about one page in ten would not render as Markdown, there is no SDK, and there is no place to watch for API changes other than deprecation banners and emails to registered systems.
See technical details5 · Access & Cost
You can start building today on the plan you already have, with no sales call and no upgrade: keys are created in the account at Admin, API. Register a free system with Follow Up Boss before you need webhooks or the newer automation endpoints.
See technical detailsEvery check, and why it scored that way.
The same 27 checks are applied to every platform. What changes is which are N-A and what the core objects mean for that kind of software. Each mark below is quoted from the run's own report. Marks are AI-generated and cover API access only.
Category 1 · Functional Coverage
11.3 / 15Object coverage
weighted coverage = 82% (9.0 of 11). Records 1.0×3: GET/POST /people, GET/PUT/DELETE /people/{id}, GET/POST /deals, PUT/DELETE /deals/{id} [OpenAPI paths; /reference/people-post, /reference/people-id-put, /reference/deals-post]; live GET /v1/people returned 2,269 records with _metadata and GET /v1/deals 156 (2026-09-22). Automations/triggers 0.5×3: enrollment and control are writable (GET/POST /actionPlansPeople, PUT /actionPlansPeople/{id} [/reference/actionplanspeople-post]; GET/POST /automationsPeople, PUT /automationsPeople/{id} [/reference/automationspeople-1, /reference/automationspeopleid]; live GET /v1/actionPlans → 200 with 30 plans), but automation definitions are read-only through the API (only GET /automations and GET /automations/{id} exist; no create, update or delete of a rule in the 156-operation file) and those two routes are "for customers with Automations 2.0 only" and "restricted to registered systems only" [/reference/automations, /reference/automationsid]; live GET /v1/automations with the operator's own key → 403 {"errorMessage":"You do not have access to this API endpoint."}; the legacy action-plan endpoints carry a deprecation notice with no date [/reference/actionplanspeople-post]. Under the check's wording (present but missing a non-critical operation) this scores 0.5; run 1 had scored 1.0 and was overruled on reconciliation. Pipelines 1.0×2: GET/POST /pipelines, PUT/DELETE /pipelines/{id} (owner only), GET/POST /stages, PUT/DELETE /stages/{id} [/reference/pipelines-post, /reference/stages-post]; live GET /v1/pipelines → 6, GET /v1/stages → 29. Custom fields 1.0×2: GET/POST /customFields, PUT/DELETE /customFields/{id} (owner only) and /dealCustomFields [/reference/customfields-post, /reference/customfields-id-delete]; live GET /v1/customFields → 25. Reporting/exports 0.5×1: no report endpoints; GET /smartLists is read-only and datasets are exported only by paging list endpoints [/reference/smartlists-get; /reference/pagination]. No critical object absent; 0.818 falls in the 0.50–0.84 band.
Core operational actions
(documentation-graded) — weighted coverage = 100% (10 of 10 over the mutable items; 91% if the non-mutable reporting/exports item is counted at 0, as runs 2 and 3 did; same mark either way). Create/update records: POST /people and PUT /people/{id} (firstName, stage, tags, emails, custom* fields) [/reference/people-post; OpenAPI PUT /people/{id}], POST /events for lead intake with dedupe and automation triggering [/reference/events-post, "Sending Leads and Activity"], POST /deals, PUT /deals/{id} [/reference/deals-post]. Fire and receive triggers: POST /events with type Registration, Property Inquiry, Seller Inquiry or General Inquiry starts action plans and automations [/reference/events-post, "Action Plan and Automation Triggers"]; POST /actionPlansPeople applies a plan [/reference/actionplanspeople-post]; POST /automationsPeople "Manually trigger an Automation for a specified Person" for registered systems [/reference/automationspeople-1]; tag and stage changes through PUT /people/{id} fire Tag Added and Stage Change triggers [help Automations 2.0 Overview]; receiving is by webhooks [/reference/webhooks-guide]. Pipelines and custom fields: POST /pipelines, PUT /pipelines/{id}, POST /stages, POST /customFields, PUT /customFields/{id} [OpenAPI]. Limitations disclosed: POST /actionPlansPeople is "planned for deprecation as part of the Automations 2.0 rollout" with no date; after an account migrates, new automations must be triggered from the API by adding a tag that a tag trigger watches [help Automations 2.0 Migration, "API"]. Live corroboration only: people records in the account carry createdVia: "API" (GET /v1/people/{id}, 2026-09-22).
Delete or lifecycle actions
(documentation-graded) — weighted coverage = 85% (8.5 of 10), exactly at the threshold. Records 1.0×3: DELETE /people/{id} [OpenAPI; llms.txt entry], stage change via stage/stageId on PUT /people/{id} and the Trash stage [/reference/people-get, "Trash Stage"; OpenAPI]. Automations 0.5×3: enroll (POST /actionPlansPeople, POST /automationsPeople), pause and resume (status = Running or Paused on PUT /actionPlansPeople/{id} [OpenAPI] and PUT /automationsPeople/{id} [/reference/automationspeopleid]), and contacted: true on PUT /people/{id} pauses action plans [/reference/people-id-put]; no unenroll or remove operation exists (no DELETE on either pairing resource), and the fixed classification lists unenroll as a principal lifecycle change. Pipelines 1.0×2: stageId on PUT /deals/{id} moves a deal, pipeline stages carry a closedStage flag so moving a deal into such a stage closes it, and DELETE /deals/{id}, DELETE /stages/{id} (not for isProtected stages) and DELETE /pipelines/{id} exist [/reference/deals-id-put; /reference/pipelines-post (request schema closedStage); /reference/stage-id-delete]. Deals also expose an Archived status in GET /deals filters but no documented way to set it through the API [OpenAPI GET /deals parameters status, includeArchived]. Custom fields 1.0×2: DELETE /customFields/{id} (owner only) [/reference/customfields-id-delete].
Change notification
weighted push coverage = 70% (7 of 10). Webhook events cover records (peopleCreated, peopleUpdated, peopleDeleted, peopleStageUpdated, peopleTagsCreated, dealsCreated/Updated/Deleted; weight 3), pipelines (pipelineCreated/Updated/Deleted, pipelineStageCreated/Updated/Deleted, stageCreated/Updated/Deleted; weight 2) and custom-field definitions (customFieldsCreated/Updated/Deleted, dealCustomFieldsCreated/Updated/Deleted; weight 2; person custom-field values fire peopleUpdated) [/reference/webhooks-guide, "Supported webhook events"]. No event exists for automation or action-plan enrollment or firing (weight 3); those can only be polled through GET /actionPlansPeople or GET /automationsPeople?status= [/reference/actionplanspeople-get; /reference/automationspeople]. Efficient incremental polling exists for people (updatedAfter, honored live) but not deals [/reference/common-filters; live s3_deals_updatedAfter total 0 of 156]. Webhooks require the account-owner key and a registered system [/reference/webhooks-guide, "Owner Permissions Required", "X-System Header is Required"]. Note: the POST /webhooks OpenAPI enum omits the pipeline, pipeline-stage and custom-field events that the guide documents.
Category 2 · Design & Reliability
7.1 / 10Modern API conventions
resource-oriented REST over HTTPS with JSON bodies and standard verbs (GET, POST, PUT, DELETE), documented in an OpenAPI 3.1 file [/reference/getting-started, "API Endpoint"; /reference/requests-and-responses; /openapi/58b53c341065f9c438aa1f7e]; confirmed live (GET /v1/people/{id} → 200 JSON, 2026-09-22).
Consistent typing
core identifiers and timestamps are consistently typed (id integer, created/updated ISO 8601 UTC strings, stageId integer, price integer or null) in the schemas and in live reads [/reference/requests-and-responses, "Date Format"; live GET /v1/people/{id}?fields=allFields]. Inconsistencies: contacted is boolean in the POST /people, PUT /people/{id} and POST /events request schemas but an integer 0/1 in responses (documented in the /people/claim response schema "contacted": {"type": "integer", "example": 0} and observed live as a number); phones[].isPrimary and emails[].isPrimary are integers 1 in responses; the "include archived" concept is a boolean on GET /people (includeTrash) but an integer "Set to 1" on GET /deals (includeArchived, includeDeleted) [OpenAPI parameters]. These are confined to flag fields.
Structured errors
errors are JSON with correct HTTP status and a human-readable errorMessage, but no stable machine-readable error code [/reference/error-responses]. Observed live 2026-09-22: GET /v1/people/999999999 → 404 {"errorMessage":"Requested resource was not found."}; invalid key → 401 {"errorMessage":"Invalid API Key or authentication credentials..."}; GET /v1/webhooks without system → 400 {"errorMessage":"Missing required field in the request: system."}; GET /v1/notARealResource → 404 with a descriptive message. Error shape also varies: the /rateLimit/* 403 example uses error rather than errorMessage [/reference/ratelimit-usage-get]. Caveat: invalid query values are silently ignored rather than rejected — limit=abc and updatedAfter=notadate both returned 200 with default paging and an unfiltered collection (2,269 records), which is undocumented.
Duplicate prevention
(documentation-graded) — no idempotency keys or request identifiers are documented anywhere in the reference or OpenAPI file. Natural idempotency covers lead intake: POST /events "will automatically de-duplicate people based on their phone number or email address" and accepts person.id to bind to an existing contact [/reference/events-post]; POST /people?deduplicate=true returns the existing person instead of creating one [OpenAPI POST /people parameter deduplicate]; GET /people/checkDuplicate exists [/reference/people-checkduplicate]. Retried POST /notes, /tasks, /deals, /appointments or /calls have no documented protection, and a retried POST /events still records a duplicate event.
Graceful handling under load
sliding 10-second window; every response carries X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Window, X-RateLimit-Context; exhausted limits return 429 Too Many Requests with a Retry-After header in seconds, with published defaults (global 250 per 10 s for registered systems, 125 unregistered) [/reference/rate-limiting]. Observed live on every response 2026-09-22 (x-ratelimit-limit: 125, x-ratelimit-remaining: 124…106, x-ratelimit-window: 10, x-ratelimit-context: global). A 429 was not deliberately triggered because the Terms of Service prohibit exceeding published limits [/legal-pages/terms-of-service §4.5]. Registered systems can also read GET /v1/rateLimit/usage and /limits [/reference/ratelimit-usage-get].
Pagination for large collections
limit (default 10, max 100) with either offset or the recommended keyset next token; _metadata returns total, next and nextLink; default ordering is documented ("reverse order by id"), and deep pagination enforces next [/reference/pagination]. Observed live 2026-09-22: page 1 {"offset":0,"limit":3,"total":2269,"next":"eyJ…"}, page 2 fetched via next and via offset=3 returned the same next three ids, limit=101 silently clamped to limit: 100 consistent with the documented maximum.
Bulk or incremental export
incremental sync is documented and honored for people (updatedAfter/updatedBefore, createdAfter/createdBefore, idGreaterThan/idLessThan) [/reference/common-filters]; live GET /v1/people?updatedAfter=2026-09-15T00:00:00Z returned 10 records all updated on or after the cutoff, and a two-sided window returned 74 records inside it (2026-09-22). Limitations: the docs warn "the updated fields may not be accurate for all records" because related records do not bump the parent [same page]; deal objects carry no updated field, GET /deals defines no updatedAfter parameter, and GET /v1/deals?updatedAfter=… returned 0 of 156 deals live; notes have no list endpoint (only GET /notes/{id}) [llms.txt]; there is no bulk or asynchronous export path, so full extracts are 100 records per call.
Webhook security and delivery reliability
(documentation-graded; runs 1 and 2 yes, run 3 partial — see reconciliation) — every delivery carries a FUB-Signature header, an HMAC-SHA256 of the base64-encoded payload keyed by the registered X-System-Key, with sample verification code; failed deliveries (non-2xx) are retried on a published schedule (1, 5, 5, 10 and 30 minutes) and webhooks with more than 50% failures over 48 hours are auto-disabled; each event carries a unique eventId, missed events can be re-requested from GET /v1/webhookEvents/:id, and consumers are told to fetch the resource uri, reconcile against their own store, and keep an events table as "the source of truth as to what webhook events have been received and processed" [/reference/webhooks-guide, "Verify the request", "Retrying webhook events", "Requesting webhook events", "Handling webhook events", "Webhook best practices"]. Disclosed weaknesses: the same page says retries continue "up to 5 times" (about 51 minutes in total) and elsewhere "for up to 8 hours"; the missed-event section refers to events "older than 3 days"; the docs never state outright that deliveries may repeat. Not live-tested (step 8 not run).
Concurrency and conflict control
documented conflict semantics exist for one write only: POST /people/claim returns 409 Conflict when the lead was already claimed [/reference/people-claim]. No ETag/If-Match, version field or 409 is documented for ordinary updates, and PUT /people/{id} overwrites the tags and phones arrays wholesale unless mergeTags=true [/reference/people-id-put]; no concurrency limits are documented (an etag header was observed on live GET responses but is undocumented and could not be exercised without a write). All three runs marked partial; two noted that "no" is also defensible.
Versioning and backward compatibility
explicit path version /v1 ("currently v1 is the only version") and an informal promise that the API "will be extended … while keeping it backward compatible" [/reference/getting-started]; the API Terms say "New versions may not be compatible with your previous implementation" and FUB may require the newest version [/reference/fub-api-tou §1]; deprecations are announced as page banners ("planned for deprecation … no date has been set") [/reference/actionplanspeople-post; /docs/oauth-authentication-and-authorization, "Deprecated GET endpoint"]. There is no written policy defining breaking versus non-breaking changes or deprecation windows.
Request traceability
no request or correlation identifier is documented; every live response carries CloudFront's x-amz-cf-id (observed 2026-09-22), which FUB does not document or state as usable with support; support is by email only [/reference/support-and-help]. All three runs marked partial; two noted that "no" is also defensible.
Service availability and status transparency
public status page "Follow Up Boss Status" with an "API" component, an incident-history page and an uptime-history page ("Uptime over the past 90 days. View historical uptime.") [followupboss.statuspage.io, /history, /uptime]; the public status API listed 50 incidents including "Widespread Service Disruption" (major, 2026-08-31, resolved) and showed the API component in partial_outage at run time [/api/v2/incidents.json, /api/v2/components.json, 2026-09-22]; the site links to it ("You can view our system status at any time") and publishes an uptime figure, although inconsistently: "99.5% System Uptime" on the security page and "99.95% System Uptime" on the Terms of Service page [www.followupboss.com/security; /legal-pages/terms-of-service]. No contractual SLA (service is "AS-IS") [/legal-pages/terms-of-service §11].
Category 3 · Access Control
3.5 / 5Read-only credentials
"API key has the same access level as the user whom the key belongs to" and "provides the same privileges as the user's login credentials"; every documented role (Owner, Admin, Agent, Lender) can write [/reference/authentication, "Basic Authentication", "Permission Levels"; help API Key, Users, Roles & Permissions]. No read-only key or role is documented, and the OAuth authorization request defines no scope parameter [/docs/oauth-authentication-and-authorization, Step 1].
Scoped credentials
scoping is by user role only: an Agent key reaches only assigned contacts and has "restricted access to things like action plans", a Lender key fewer actions still, an Admin cannot use webhooks, and pipelines, custom fields and webhooks are owner-only [/reference/authentication, "Permission Levels"; /reference/pipelines-post; /reference/customfields-post; /reference/webhooks-guide]. The API Key Restrictions power-up controls who may create keys, not what a key can do [help Power-Up: API Key Restrictions]; OAuth defines no scopes.
Multiple keys
any number of named keys per user, listed with created and last-used times and the integrations that used each [help API Key, "Creating an API Key", "How can I see a list of my account's API keys?"]; the live /me body exposes a canCreateApiKeys flag (field name only).
Rotation and revocation
self-serve delete ("Integrations using that API key will lose access … and stop working immediately") and self-serve creation of a replacement [help API Key, "How do I delete an API key?"]; keys are shown once at creation [/docs/start-here-brand-new-integration]; OAuth grants can be revoked with DELETE /v1/oauthApps/revokeAccess [/docs/oauth-authentication-and-authorization, Step 6].
Test and production isolation
(run 1 yes, run 2 partial, run 3 N-A — see reconciliation) — the vendor's integration guide directs developers to a separate free 14-day trial account ("a full-featured account", created "so that you can see the result of your API requests") that can be converted to a non-expiring dev account by emailing product@followupboss.com, with its own API keys generated at Admin > API [/docs/start-here-brand-new-integration, "Creating a trial Follow Up Boss account", "Generate an API Key in your Follow Up Boss account"]. Because it is a separate account, its credentials and data are isolated from the operator's live account. Limitation: this is a separate production tenant rather than a sandbox mode of the operator's own account, and the dev-account conversion is email-mediated.
Category 4 · Docs & AI-Ready
2.5 / 5Complete self-serve reference
a public reference covers authentication, every endpoint, parameters and request schemas, with guides for pagination, filters, errors, rate limits and webhooks [/reference/getting-started and linked pages; llms.txt]. Worked examples and response definitions are uneven: 38 of 156 operations carry only a {} placeholder as their 2xx example, including core writes POST /events, POST /people, PUT /people/{id}, DELETE /people/{id}, POST /notes, POST /actionPlansPeople and GET /automations; the 2xx examples for GET /people, GET /people/{id} and GET /deals are not valid JSON (truncated with ellipses or trailing commas); request-body examples exist for 23 operations; the OAuth oauthApps endpoints appear only in guides [/openapi/58b53c341065f9c438aa1f7e, computed 2026-09-22].
Reliable machine-consumable integration path
(run 1 yes, runs 2 and 3 partial — resolved to partial on the evidence) — a published OpenAPI 3.1 JSON covers all 156 operations with typed parameters and request bodies [/openapi/58b53c341065f9c438aa1f7e; listed at /openapi], but it is incomplete where it matters most for code or tool generation: 67 of 156 operations have no typed 2xx response schema (schema absent or with zero properties), including GET /people, GET /people/{id}, GET /deals, POST /events, POST /people, PUT /people/{id} and DELETE /people/{id}, so a generated client has no response types for the two critical record types; one path is //textMessageTemplates, the two rate-limit paths are written /v1/rateLimit/... under a server URL that already ends in /v1, /webhookEvents/:id uses colon syntax without a declared path parameter, and some enums embed quotation marks. No official SDK exists: the FollowUpBoss GitHub organization's only API repository, fub-api-examples, holds bash and PHP lead-submission samples, is archived, was last pushed 2023-04-03, and its README links to a legacy documentation URL [api.github.com/orgs/FollowUpBoss/repos; README]. No first-party MCP server was found; the MCP servers located are third-party.
AI-readable documentation
/llms.txt indexes every guide and endpoint page with descriptions and instructs "Append .md to any documentation page URL to get its markdown version" [/llms.txt]; 174 of 193 pages rendered as Markdown, but 19 endpoint pages (mostly /{id} operations, including GET /people/{id}, DELETE /people/{id}, GET /tasks/{id}, PUT /tasks/{id}, GET /stages/{id}, GET /customFields/{id}) returned the 580 KB HTML application shell on three attempts (2026-09-22); no llms-full.txt exists (404).
Kept current
a public product "news feed and changelog" exists but is product-level, has no API category, and is rendered client-side [updates.followupboss.com/en]; the docs carry deprecation banners with no dates [/reference/actionplanspeople-post]; API responses tell unregistered callers that registered systems "will be notified about important changes to the API" (observed in _metadata.notice, 2026-09-22), so change notices go by email to registered systems; the newest pages (/reference/ratelimit-usage-get) use 2026 dates and help articles carry recent update stamps (Automations 2.0 Overview 2026-07-22; Plan Breakdown 2026-09-11). There is no API changelog (docs.followupboss.com/changelog → 404).
Category 5 · Access & Cost
15 / 15Self-serve API key
"Go to Admin > API, Click Create API Key … By default, anyone can create an API key" [help API Key, "Creating an API Key"; /docs/start-here-brand-new-integration, "Generate an API Key"]; confirmed by live authentication with an operator-created key (2026-09-22). Note: webhooks, Automations 2.0 routes and the rate-limit endpoints additionally require a registered system, obtained through a self-serve web form (system name, system ID, email, name, organization, terms checkbox) [apps.followupboss.com/system-registration]; whether the system key is issued instantly was not verified.
Not commercially gated
API keys are generated "within your FUB account" with no plan condition [help API Key]; all plans include "Unlimited contacts, lead sources and integrations" and the site markets the "Open API" for custom integrations [/pricing; /pro, "Integrations"]; the plan breakdown lists no API restriction [help Follow Up Boss Plan Breakdown]. Caveat: Automations 2.0 must be enabled by the account owner in an irreversible but free migration, and its API routes are open only to registered systems [help Automations 2.0 Migration; /reference/automations].
What works
- Read and write access to contacts, deals, pipelines, stages, tasks, notes and custom fields
- Lead intake through one events endpoint that de-duplicates by phone or email and triggers automations
- Signed webhooks with a published retry schedule and a way to re-request missed events
- Rate-limit headers on every response and a documented 429 with Retry-After
- Cursor pagination with a total count, verified live across pages
- A public status page with an API component, incident history and 90-day uptime
- Any number of named keys per user, each revocable instantly
- A separate trial or dev account documented for testing
- An llms.txt index with Markdown versions of the documentation
- Self-serve keys on every plan, with no API fee
What to watch
- No read-only or scoped keys: every key carries the full rights of the user who made it
- Automation rules can only be built in the app, and Automations 2.0 endpoints require a registered system
- No webhook event when an automation or action plan starts or finishes
- Errors carry a message but no machine-readable code, and bad query parameters are silently ignored
- No idempotency keys, so a retried note, task, deal or call can be created twice
- Changed-since sync works for contacts only, not deals, and there is no bulk export
- No documented conflict control on ordinary updates
- The OpenAPI file has no typed responses for 67 of 156 operations, including contacts and deals
- No SDK, and the only sample repository is archived
- No API changelog; deprecations are announced as undated banners
- Writes were graded from documentation, not tested live
Check it yourself.
Both files behind this page, in full.
NOTE: Grades are AI-generated from the published grading file, and cover API access only.
Follow Up Boss’s full report
The complete markdown report this page is built from, including the evidence packet, the run metadata and every check in full.
Download the Follow Up Boss reportThe grading file
The exact rubric behind every score on this page. Same file, every platform. Run it yourself and compare.
Download the methodologyFound a factual error in your grade?
Tell us and we will fix it. Every mark on this page traces to a specific piece of first-party evidence or a live API call, and the full report is published so you can see exactly what was checked and what it was checked against.
Confirmed factual errors are corrected immediately.
Everything else waits. We do not rescore piecemeal on request, because a board where some vendors have been re-run and others have not is not a fair comparison. Shipped improvements, changed documentation and disagreements about judgement all go into the next full rerun.
Contact us with a factual errorMethodology inspired by SaaStr’s AI Agent API Report Card.