The Supplier Login Nobody Owned
Most supplier portals give each supplier one login, and every supplier shares it: the salesperson who quotes, the dispatcher who ships and the clerk who chases payment. Nobody owns it, nobody can be removed from it, and nobody would notice if a stranger signed in. What a supplier account needs once more than one person uses it, and how ours handles contacts, rights, sessions, alerts and machine access.
- Written by
- Washingtone AuraFounder, AWRA OpsHub
- Issued
- Build
- Initial
The stationery supplier had one portal login, set up by their sales manager three years ago. The password was on a sticky note in the dispatch office, in the accounts clerk’s phone, and — it emerged later — in the head of the sales manager who had left in March for a competitor. In June that competitor began winning quotes by margins that looked uncannily well judged. Nobody could say whether the old login had been used, because nobody could see where it was signed in, and nobody could remove one person from it without changing the password on everyone.
A buyer’s own staff accounts would never be run like that. Each person has their own sign-in, their own rights, and a departure ends their access on the day. Supplier accounts are usually run like the sticky note, for a simple reason: the portal was designed around the supplier as one organization, and the people inside it were the supplier’s business.
One supplier, several people
A supplier account can now hold several contacts. The first — every login that existed before contacts did — is the primary contact, who holds every right and cannot be removed. The primary invites colleagues from the Team screen and decides what each of them may do.
| Right | What it opens |
|---|---|
| Quote on RFQs | See RFQs sent to the supplier and submit or revise quotations |
| Purchase orders | See orders, acknowledge or decline them, update shipping |
| Upload invoices | Submit bills and invoices against an order |
| View payments | See what has been paid and what is outstanding |
| Company documents | Upload and renew certificates and licences |
| Manage contacts | Invite colleagues, set their rights, remove them |
Only the primary contact can give someone the right to manage contacts, so a colleague trusted with the team cannot quietly hand that trust to somebody else. The portal menu hides what a contact cannot use, and payment amounts are hidden from anyone without the payments right — the dispatcher sees orders, not what the supplier is owed.
The check is on the server, not the menu
Every supplier route on the web, in the app and through the API asks the same question: does this contact hold this right? A hidden menu item is a courtesy. The refusal is the control, and it applies to a token as much as to a person — a token created before a right was withdrawn stops working the moment the right goes.
A shared login cannot lose one person. Separate contacts can lose one person on the day they leave.
Where each contact is signed in
Each contact has a security page listing where they are signed in: one row for each browser and one for each app or API token, with when it was last used. From there a contact can sign out one device, sign out everywhere except the one in front of them, or revoke a token. Removing a contact from the team deletes all of their tokens with them.
The browser row is deliberately keyed on the contact and the browser rather than the network address. A phone on mobile data changes address every hour; a list that grew a row each time would be a list nobody reads.
Alerts for a sign-in that looks unusual
Two things count as unusual: a browser or app this contact has not used before, and a country this contact has never signed in from. The very first sign-in after an invitation is expected to be new and does not alert. Either case sends one email to the contact — an email that cannot be switched off — and leaves a notice on the security page with two buttons: This was me, and Sign it out.
The alert is a new laptop the contact just set up
This was me
The notice is cleared and the device stays signed in.
The contact does not recognise the sign-in
Sign it out
That device is signed out at once. Change the password and, if it is not on yet, turn on two-step sign-in.
The alert names a colleague’s device on a shared contact
Give them their own contact
Invite the colleague with only the rights they need, then sign the shared device out.
Two-step sign-in with recovery codes was already available to suppliers, and a buyer can require it. Separate contacts make that requirement practical: each person sets up their own authenticator instead of one phone holding the code for the whole supplier.
When the supplier is a system, not a person
Larger suppliers want their order system to read RFQs, submit quotes, acknowledge orders and send invoices without a person retyping anything. They get integration tokens, created by a contact in the portal and shown once. Only a hash is stored. Each token carries scopes — read RFQs, write quotes, read orders, acknowledge orders, send shipment notices, send invoices, propose catalogue prices — can be given an expiry, and can be revoked. A token acts as the contact who created it, within that contact’s rights, so it can never do more than the person behind it. Requests are limited per token, to sixty a minute and fifteen hundred an hour.
-
Create a token with only the scopes the system needs
An invoicing integration needs to read orders and send invoices. It does not need to quote.
-
Copy it once, into the supplier’s system
It will not be shown again. A lost token is revoked and replaced, never recovered.
-
Add a webhook endpoint
Choose the events: a new RFQ invitation, an order issued, an order changed, a payment made. Press the test button to see a delivery arrive.
-
Verify every delivery
Each one is signed with an HMAC-SHA256 over its timestamp and body. Reject anything that does not verify.
Webhook addresses are checked when they are saved and again on every send, so an address that is changed later to point inside a private network is refused at the moment it would be used. A failed delivery is retried up to six times over about four hours, every attempt is in a delivery log the supplier can read, and an endpoint that fails twenty-five times in a row is switched off rather than retried forever. A price a supplier proposes through the catalogue endpoint changes nothing on its own: a buyer approves it before it reaches the contract.
Four questions to ask about your supplier portal
How many people use each supplier’s login?
What you will probably hear
One, we think.
How to read it
Ask the suppliers. The answer is almost always "everyone in the office", and that is the account a departing employee keeps.
Can a supplier remove one person without changing everyone’s password?
What you will probably hear
No.
How to read it
Then nobody is ever removed. Separate contacts are what make a departure a single action.
Would anyone know if a supplier login was used from a new place?
What you will probably hear
Not unless something went wrong.
How to read it
An alert to the person whose account it is costs nothing and is the only early warning there is.
What can a supplier’s API key do?
What you will probably hear
Everything the supplier can.
How to read it
A key should carry scopes, act as one named person, and stop working the moment that person’s rights change.
Verdict
A supplier account is used by several people and, increasingly, by a machine. Treat it that way: a primary contact who owns it, colleagues with their own sign-ins and only the rights they need, a list of where each is signed in, an alert on a sign-in that looks new, and integration tokens that are scoped, revocable and tied to a person. The sticky note then has nothing left to do.
Further supplier account controls
Contacts and rights, sessions, sign-in alerts, scoped integration tokens and signed webhooks are in place on the supplier portal and its API. These extend them.
The app menu shaped by each contact’s rights
Hiding screens a contact cannot use in the mobile app, as the web portal does, rather than letting the server explain the refusal.
Integration tokens and webhooks managed from the app
Creating, revoking and testing them on a phone, with the delivery log alongside.
A notification bell in the supplier portal
Sign-in alerts, new RFQs and order messages collected in one place inside the portal, next to the email.
Allowed networks per integration token
A list of addresses a token may be used from, for suppliers whose systems run from fixed servers.
Each builds on the contact rights and device records the portal already keeps.
Tell us what your suppliers needSee the vendor portal
Supplier contacts with their own rights, sessions and sign-in alerts, quotes and orders on the web and in the app, and an API with signed webhooks for suppliers’ own systems.
Explore the vendor portalFrequently asked questions
Can a supplier have more than one login?
Yes. A supplier account can hold several contacts, each with their own sign-in and their own rights. The primary contact holds every right, cannot be removed, and decides what each colleague may do.
What happens to a supplier contact’s access when they leave?
Removing them from the supplier’s team ends their sign-in and deletes every integration token they created. Nobody else’s password has to change.
When does a supplier get a sign-in alert?
When a contact signs in from a browser or app they have not used before, other than the first sign-in after their invitation, or from a country they have never signed in from. The alert email is always sent and a notice appears on their security page.
What can a supplier integration token do?
Only what its scopes allow, and never more than the contact who created it is allowed to do. Tokens are shown once, stored as a hash, can expire, can be revoked, and are rate limited.
How do suppliers know a webhook really came from AWRA?
Every delivery is signed with HMAC-SHA256 over its timestamp and body using a secret the supplier holds. A delivery that does not verify should be rejected.
