Account · BidNomy

Status: in development. Profile, two-step verification, the organisation, seats, roles, invitations, the 14-day trial and paid plans are live. Leaving an organisation and transferring ownership are not.

Account holds everything about you rather than about the market. Your profile is the name and email on the seat. The organisation is the workspace everything else belongs to: pursuits, saved searches, files and pipelines are the organisation's, not the individual's, so people can join and leave without work disappearing with them. Roles are owner, admin and member, and only the first two can invite people, remove seats or change the plan.

Billing shows the plan the organisation is on, what it renews at, and everything that has happened to it. A new organisation starts on a 14-day trial of Growth the moment it is created, with no card and nothing charged; when the trial ends the workspace is locked until somebody chooses a plan, and no account is ever moved onto a paid plan without somebody choosing it.

Signing up and signing in

The sign-up form asks for your name, your organisation (it becomes the workspace name), your role from a list of twelve, and — optionally — what you sell to government, then a work email and a password. Personal email providers such as Gmail and Outlook are not accepted. Signing up from an invitation skips the organisation, role and what-you-sell questions, because you are joining a workspace that already exists. Your role and what you sell are shown on the Account page and decide nothing.

Sign-up, sign-in and password reset each carry a Cloudflare Turnstile check. Most people see a brief tick and nothing else; if the check fails, the form says so and lets you try again.

Two-step verification

Two-step verification is optional, and it is yours rather than the organisation's: each person turns it on for their own sign-in. With it on, signing in takes your password and then a six-digit code from an authenticator app on your phone — Google Authenticator, Microsoft Authenticator, 1Password or another app that makes these codes — so somebody who learns your password still cannot sign in without your phone.

Turning it on. The Two-step verification block on the Account page has Turn on two-step verification. Add a new account in your authenticator app, scan the QR code the page shows (or type the setup key if you cannot scan), enter the six-digit code the app shows for BidNomy and press Verify and turn on. The block then says "On since" and the date. Any other device you are signed in on is asked for a code on its next page.

Signing in. After your password, a second step titled "Enter your code" asks for the code. The code changes every 30 seconds; enter the one showing now. A wrong code keeps you on that step with a message, and Sign out is there if you want to stop. A password-reset or confirmation link from an email asks for the code too before it opens the workspace.

Turning it off. Turn off asks for a code from the app first, then Turn off two-step verification. After that your password alone signs you in.

There are no backup codes. If you lose your authenticator, contact support to have it removed; you then sign in with your password alone and can turn it on again from the Account page. API keys are not asked for a code, and a key made before you turned it on keeps working until you revoke it.

Appearance

The Appearance block on the Account page chooses the look: System, Light or Dark. System is the default and follows your device's light or dark setting, changing when it does. Light or Dark keeps that look whatever the device does. The choice is kept on this browser only, and the same switch sits in the top bar on a larger screen.

Team and seats

Everything the workspace holds belongs to the organisation: pipelines, pursuits, tasks and tags, saved searches, saved prompts, uploaded documents, notification channels and the custom fields on a pursuit. Somebody who joins sees the work that is already there without anybody moving it, and somebody who leaves takes none of it with them. Threads on the AI page and API keys are the exception — those stay personal, because they are a person's own working notes and a person's own credentials. Removing somebody revokes their API keys at the same moment, so nothing they hold keeps reading this workspace; their threads stay theirs.

A seat is one named person, or one invitation waiting to be accepted. Account › Team shows the count as a sentence — "3 of 5 seats in use, 1 invitation pending" — and that sentence is what the API checks against when you send the next invitation, so the page and the refusal cannot disagree. Revoking an invitation gives the seat back immediately; so does removing somebody. Launch and Launch Plus seat one person, Growth and a trial seat five, and Scale is unlimited.

Three roles.

Owner — the person who created the organisation. One per organisation, and the role cannot be given away or taken: transferring ownership is not built yet.
Administrator — everything a member can do, plus inviting people, changing somebody's role, removing somebody, renaming the organisation and moving the plan.
Member — the whole shared workspace, read and write. A member sees the Team page in full, including who is in it and how many seats are left, and can change none of it.

Inviting. An administrator sends an invitation to a work address from Account › Team. The invitation email carries a link that is good for 14 days, and the link is the only place it exists — BidNomy stores a one-way hash of it and can never show it to you again. Resend issues a fresh link and retires the old one; Revoke withdraws it and frees the seat. Accepting is done signed in as the address it was sent to: another account is refused, and told which address to use.

One organisation per person. An account belongs to one organisation at a time. The empty workspace every new account starts with is replaced when its owner accepts an invitation, so a colleague who signs up from your invitation lands in yours; somebody whose own organisation has a member or an open invitation in it cannot accept an invitation into another. Leaving an organisation is not built yet; until it is, an administrator removing somebody is what ends a membership, and that person's next visit starts them a new, empty organisation of their own.

Two things are shared more than you might expect, and one less.

The inbox on Account › Notifications is the organisation's, so read and unread are the team's: a colleague opening a notification marks it read for everybody. Deciding what each person has seen is a later step, and until then one team reading one inbox is better than four copies of the same row.
The manual run limit on saved prompts — twenty Run-now presses a day — counts the organisation's runs, not yours. Scheduled runs are unaffected.
A file is the organisation's, bytes included: uploads are stored under the organisation rather than the person, so every member can read the text and download the original. Documents uploaded before this changed stay readable by everybody too — the owner's own account is what an organisation of one was already keyed by.

Plans and billing

Account › Billing is the plan the organisation is on, not yours: everybody in the team is on it, and only the owner and administrators can change it. A member sees the whole page and can press none of it. What a plan commits you to — annual renewal, notice of a price change, and what cancelling does — is in the terms of service.

The 14-day trial. Every new organisation starts one the moment it is created — it is Growth for fourteen days: five seats, 1,000-row exports three times a day, 1,000 AI credits, the full workspace — with no card and nothing to cancel. The sidebar shows how many days are left, and the owner is emailed two days before it ends. On the fifteenth day the workspace is locked: lists show no records, record pages and exports say the trial has ended, and a banner at the top of every page links to Billing. Nothing is deleted — saved searches, pipelines, files and the team are all kept, and everything opens again the moment somebody chooses a plan. A trial is once per organisation for ever; cancelling a paid plan later does not bring it back. (An organisation created before 27 September 2026 is on early access and can still start its trial from the Billing page.)

Buying a plan. Buy on any of the three priced cards opens Stripe Checkout. Prices are annual, in Australian dollars, exclusive of GST; the card details go to Stripe and never to BidNomy. Your plan is live within a minute of the payment going through — usually a second or two — and the Billing page says so if you get back before it lands. Scale is quoted rather than bought: its card writes to solutions@byauto.com.

Invoices, the card and cancelling. These happen in Stripe's own billing portal, which Manage subscription opens: update the card, download every invoice, or cancel. Cancelling leaves the plan on until the end of the period you have paid for, and the page then says "Cancels on …" rather than pretending it has already gone. If a payment fails, the plan stays on and the page says the card needs attention — a failed card mid-bid is a message to send, not a workspace to switch off.

Changing your plan

Moving up happens at once. On the Billing page, a plan above yours shows Upgrade to …. The difference for the rest of your year is charged straight away to the card on file, the new plan's limits apply immediately, and your renewal date does not move. AI credits follow the plan: the larger monthly allowance applies for the rest of the month, with what you have already used this month counted against it. If the card is declined nothing changes — update it in Manage subscription and try again.

Moving down is never done mid-year, and nothing is refunded. Cancel at renewal in Manage subscription, then buy the smaller plan when the year ends — the lower cards on the Billing page say exactly that, and the date. A smaller plan has fewer seats: if the team (members plus open invitations) is larger than the plan seats, Buy says how many people to remove or invitations to cancel first, with a link to the Team page. Nobody is ever removed by a plan change: the seats are freed first, then the smaller plan is bought.

When a paid plan ends — you cancelled and the year ran out, or the card could not be charged — the workspace stays read-only for 7 days: the records your plan covered still open, search and reports still work, and your pipelines and pursuits are all there. Exports, alerts, saved prompts, AI research and new invitations stop, and a banner on every page says when the week ends. Buying any plan on the Billing page brings everything back. After the week the workspace closes like an ended trial; nothing is deleted.

Billing history. Every event Stripe sends — a payment, a renewal, a plan change, a cancellation — is listed on the Billing page with the date and what was done with it. It is the same record BidNomy acts on, so if the plan on the page is not what you expect, that list is where the answer is.

API keys

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 Account › API keys, and it carries exactly your access — the same records, your plan's export 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)

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 Account › 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.
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.
ask — BidNomy's own research agent. The conversation it starts is yours and appears on your AI page, so an answer from your editor and an answer from the portal have the same audit trail.
list_pursuits, get_pursuit, create_pursuit, add_task and capture_dashboard — your own capture workspace, so an assistant that has just found a worthwhile ATM can put it on a pipeline and give it a checklist 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 capture tools that write (create_pursuit and add_task) write only to your own workspace. ask and run_skill spend model time and are capped per day; the other fourteen tools are not. A key is personal — a service token, the kind that runs our own scheduled jobs, is refused on the MCP server on purpose.

Notifications

Everything that happens in your capture workspace lands in one inbox, on Account › Notifications, whether or not you have set anything else up: a pursuit created, moved, won, lost or deleted; a task added or ticked off; the tasks that are due in the next 48 hours; and a saved search that found something. The bell in the top bar carries the unread count, each row links to the thing it is about, and nothing is ever deleted to make room until you are five hundred rows deep. The inbox is the organisation's rather than yours: a colleague opening a row marks it read for everybody.

A channel decides where else those notifications go. You can have ten, of four kinds:

Webhook — an HTTPS endpoint of yours, signed so you can prove the request came from us.
Slack — an incoming webhook from a Slack app; the bid channel gets a message with a link.
Email — the address on your account. Nothing to configure, and nothing to get wrong.
Jira — a Jira Cloud project. A new pursuit becomes an issue, with its pipeline, stage, value, win probability, source record and a link back.

Every channel subscribes to the event types it should carry, and the list you are offered depends on the kind. A Jira channel is offered a new pursuit and the test, and nothing else — an issue per stage change is noise somebody has to close. An email channel is never offered the saved-search digest, because the alert email already is that digest and a second copy is worse than none.

Test sends one notification to one channel immediately, even while that channel is switched off, and shows you the result: the status code, and a masked error line if it did not work. That is the point of it — a wrong Jira project key or a revoked Slack hook should be a row in a log with a number on it, not something you find out about the week a bid is due.

Webhook signature

Every webhook request carries three headers — X-GovAUTO-Event (the event type), X-GovAUTO-Delivery (this attempt's id) and X-GovAUTO-Signature, an HMAC-SHA256 of the raw body under your signing secret, written sha256=<hex>. Verify it before you trust the payload:

import hashlib, hmac

def verify(secret: str, body: bytes, header: str) -> bool:
    expected = hmac.new(secret.encode(), body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(f"sha256={expected}", header)

Sign the bytes you received, not a re-serialised copy of the parsed JSON — key order and spacing are part of what was signed. hmac.compare_digest rather than == keeps the comparison constant-time.

Delivery and retries

A write schedules one delivery attempt straight away, so a webhook usually lands before the page has finished re-rendering. Anything that attempt could not send waits for the sweep, which runs every ten minutes and backs a failure off 1, 5, 30 then 120 minutes; after the fifth attempt the delivery is marked gave up and appears in that channel's log with the last status code it saw. The daily "tasks due" digest is raised at 07:00 and delivered in the same pass. An account with nothing due gets no notification at all.

Secrets are write-only. A channel's configuration comes back from the API masked to its last six characters and there is no route that returns it in full, so nothing you store here can be read back out of the product — by you, by us, or by anything holding one of your API keys. Editing a channel and leaving a secret box empty keeps what is stored, which is the only thing it can mean.

Sending a pursuit to Jira by hand

A pursuit created before you added the Jira channel never raised the event that would have made its issue. The pursuit page has a Send to Jira button for exactly that; once an issue exists the button becomes its key, and pressing it again is safe — BidNomy answers with the issue it already made and posts nothing.

Export limits

Every CSV download — a filtered list, or one block of a report — is capped at a number of rows by the plan on your account:

Launch and Launch Plus — 100 rows per export, 2 exports a day.
Trial — 1,000 rows per export, 3 exports a day, for as long as the trial runs.
Growth — 1,000 rows per export, 3 exports a day.
Scale — 3,000 rows per export, 10 exports a day.
Early access, and any account with no plan attached — 50 rows per export, 10 exports a day.
Trial ended — none, until a plan is chosen.

The plan you are on is shown on the Billing page, with the numbers beside it. Going over the row limit does not refuse the download: you get the first rows of the result in the order you sorted it, and the file itself says which limit applied.

The exports a day are shared by the whole organisation — every member and every API key draw on the same count — and the count starts again at midnight Sydney time. Only a download that produced a file counts; a report block and the capture dashboard never do. The Export button on each list shows how many are left ("1 of 3 exports today"); once they are used it says so, and a script calling the API gets a 429 with a Retry-After header and the X-Export-Quota, X-Export-Quota-Used and X-Export-Quota-Reset headers every export carries.

Lists themselves are limited too, to stop a script paging through the whole register: an organisation may make 120 list or search requests a minute. Ordinary browsing stays well under it; a script that does gets a 429 with Retry-After.

The plan belongs to the organisation, so a change made for the team reaches everybody in it on their next page load rather than when their access token happens to refresh.

What you will be able to do

Edit your profile and change your password.
Leave an organisation, and hand ownership of one to somebody else.
Assign a notification to a colleague rather than to the whole workspace, and have read and unread be yours rather than the team's.