API keys and MCP

API keys

API keys are part of the Enterprise plan: on any other plan, including the trial, a key cannot be created and an existing key is refused with "API keys and the MCP server are part of the Enterprise plan" (a 403). Keys you already hold stay listed on the API keys page and can still be revoked on every plan.

An API key lets something that is not this browser read BidNomy as you: your own script, a bid tool, or an AI client over MCP. It is created on the API keys page, and it carries exactly your access — the same records, your plan's row limits, your own uploaded files, and nothing anyone else can see.

• A key is shown once. BidNomy stores a fingerprint of it and the first twelve characters, and nothing else — so nobody, including us, can show you a key a second time. Copy it when you create it; if you lose it, revoke it and make another.
• A key cannot manage keys. Creating and revoking need this page and a signed-in session. That is deliberate: a key that leaks cannot make another of itself, and cannot revoke the key you would use to shut it down.
• Ten live keys per person. Revoking is free and frees a slot. A revoked key stays in the list, marked with the date, so a credential is always accounted for.
• Revoking takes up to a minute. The API remembers a key's answer for sixty seconds so a busy client costs one lookup a minute instead of one per request. If you need it dead this second, tell us and we will restart the service.
• A suspended account's keys stop too. If we suspend an account, its keys stop working within a minute along with its sign-in, and answer "account suspended". So do the keys of somebody removed from your organisation: removing a person revokes their keys.
• Last used is approximate. It is written at most once every five minutes per key, for the same reason.

Connect an AI client (MCP)

The MCP server is part of the Enterprise plan, like the API keys it takes: on any other plan it refuses the key.

BidNomy runs a Model Context Protocol server, so Claude Code — or any MCP client that supports HTTP servers — can work with Australian procurement records directly. The API keys page shows the server URL and two ready-to-paste snippets: a claude mcp add command, and a JSON block for everything else. Both need one of your keys as a bearer token.

What your client gets:

• search_records and get_record — search and open approaches to market, contract notices, standing offers, grants, planned procurement and the state and territory records your plan includes.
• search_payments — search the payments state and territory buyers have made (today, the ACT's Notifiable Invoices Register), by words, paying entity, supplier ABN, contract number, date and amount.
• search_grant_payments — search the grants state agencies have paid (today, Queensland's QGIP), one row per payment line per financial year, by words, financial year, agency, program and recipient ABN.
• query, describe_table and list_tables — read-only SQL over the same database, with the curated schema notes that make it writable.
• list_files and read_file — the tender documents you uploaded to BidNomy, read a slice at a time.
• list_skills and run_skill — BidNomy's named jobs, run from your client, with the report returned.
• search_guide — search this user guide, with a link to the section that answers.
• ask — Bower, the BidNomy assistant. The conversation it starts is yours and appears in Bower › Chat, so an answer from your editor and an answer from the portal have the same audit trail.
• list_bids, get_bid, create_bid, add_task and business_development_dashboard — your own pipelines, bids and tasks, so an assistant that has just found a worthwhile ATM can put it on a pipeline and give it tasks without you leaving the editor, or read the dashboard's figures.

Nothing an AI client does here can change a record: the procurement database is read-only, and the two business development tools that write (create_bid and add_task) write only to your own workspace. ask and run_skill spend your organisation's AI credits, as a question in the portal does, and are capped per day; search_records, get_record, search_payments, search_grant_payments and query count toward the same list limits and daily reading limit as the portal's lists (see Downloads and limits). An AI reads at most 100 rows from one query, 50 records from one list tool and 50 search hits a call. A key is personal — a service token, the kind that runs our own scheduled jobs, is refused on the MCP server on purpose.