Build on VETR: a real developer reference, and MCP
The API has been available on Professional and Enterprise for a while. Its documentation was a summary rather than a reference — it listed twelve of the twenty-five endpoints, pointed you at a settings page that does not exist to create your token, and never mentioned that a newly created token is read-only by default, which is why writes came back “forbidden” with nothing to explain it.
- Every endpoint is now documented — all twenty-five, with query parameters, request bodies, what each returns, and which token ability it needs. The page is generated from the API itself, so it cannot drift out of step with what the platform actually serves.
- Token abilities are explained before you need them, along with every condition a request has to satisfy and what each error code means. Previously only the rate limit was documented.
- Code samples in curl, JavaScript, Python and PHP, instead of one curl line.
- Webhooks are described as what they are — shipped, and delivering signed payloads. The page had been calling them “coming soon”.
The MCP server is documented for the first time
VETR runs a Model Context Protocol server, so an AI assistant can work with your proposals, compliance status, VETR score and teaming partners directly — without you copying anything into a chat window. It has been live and reachable with your existing API token, and it was documented nowhere. It now has its own section: the endpoint, how to authenticate, every tool, and which ones need a write-scoped token.
Both the API and MCP are Professional and Enterprise features, and that entitlement is now verified on every request rather than only when a token is created. If your subscription ends, the tokens issued under it are revoked with it. Nothing changes for a current subscriber.
Certification renewals now reach the people who need them
This one was ours, and it was quiet. VETR emails you at ninety, thirty and zero days before a set-aside certification expires, shows a banner on your dashboard, and blocks a bid on a set-aside whose certification has lapsed. All three read one date — and for any certification backed by an uploaded certificate or a SAM.gov verification, that date was never being recorded. So the customers who had done exactly the right thing were the ones getting no warnings at all.
- An approved certificate’s expiry now reaches the reminders, the dashboard banner and the bid-integrity check.
- There is a recertification checklist on your certifications page: the countdown, the agency you recertify through, and the concrete steps for that specific certification. The emails and the dashboard banner now land there, rather than on the settings form.
- An expired EDWOSB is judged against your EDWOSB date, not your WOSB one. They are separate certifications with separate expiry dates, and a current WOSB was masking a lapsed EDWOSB on EDWOSB set-asides.
Your WOSB eligibility answers are kept
The WOSB / EDWOSB eligibility check asked seven questions and then forgot them — reload the page and you started again from scratch, with nothing recorded about what your organisation had assessed. Your answers are now saved with the date and who ran it, the wizard opens with them filled in, and it tells you when the annual reassessment is due. Previous assessments are kept rather than overwritten. This remains a self-assessment, not a certification.
Opportunities and sign-in
- The opportunity feed no longer depends on a single rate-limited key. It now tries the primary data source first and falls back to SAM.gov, so a daily call cap on one provider no longer empties the feed.
- Two-factor sign-in submits when you finish typing the code, on the sixth digit — and never while you are typing a recovery code.
- The dashboard header counters appear. They were being sent under a name the page did not read, so they had never once rendered.
- The government-updates admin page reports freshness per source rather than as one figure, which had been hiding a source that stopped updating nine days earlier.
Accessibility
VETR’s accessibility checks ran against the desktop layout only. They now run against mobile as well, on every build. Doing that found three real problems, all fixed — most notably the organisation switcher in the header, which on a phone had no accessible name at all for anyone using a screen reader.
Your data, the GovCloud boundary, and the guarantee that AI processing stays inside it are unchanged.