API
The BidBlender API should eventually give customers a direct way to bring opportunity intelligence into their own workflows, data models, and internal systems without forcing every interaction through the UI.
What the API should expose
Opportunity records, assessments, decision states, connector status, and organisation context are the most obvious initial API surfaces.
Why it matters
Some customers will want BidBlender to sit inside a broader revenue, bid, or data stack. An API makes that possible without reducing the product to manual exports.
What should be stated carefully
The site should signal the API as part of the platform direction, but distinguish clearly between current internal APIs and any future customer-facing API program.
Where API value is strongest
Teams with their own dashboards, BI layers, workflow tools, or internal knowledge systems will benefit most from direct access to structured BidBlender outputs.
Frequently Asked Questions
Is there a customer API today?
This page should frame the API as part of the platform direction unless and until a formal customer-facing API is released with authentication, docs, and support expectations.
What would the API be used for first?
The highest-value early use cases are pulling opportunity assessments, pushing internal context, and synchronising structured decision outputs into customer systems.
Why should the site include this page now?
Because it helps signal the platform direction to technical buyers, data teams, and implementation-minded customers without overclaiming current delivery.
How should API access be commercialised?
API access is a natural candidate for higher-tier plans or usage-governed packaging, especially where customers want deeper integration or higher-volume programmatic usage.