Automating Vendor Portals for Procurement and Supply Chain Teams

A procurement team tracking a single purchase order might need three logins to get the full picture: the supplier's order-status portal for shipping updates, a separate invoicing portal for payment terms, and a compliance portal for certifications. None of them share an API, none of them share a login, and a supplier onboarding update means learning a fourth portal with its own layout. Enterprise procurement platforms solve the sourcing and contract side well. What they rarely reach is the long tail of individual vendor portals—the systems suppliers actually built for their own customers to self-serve, one supplier at a time.

The Long Tail of Vendor Portals

A mid-size supply chain can easily involve dozens of vendors, each with its own web portal for order status, ASN tracking, invoicing, or compliance documentation. Building a direct integration against each one means a new auth flow, a new schema, and a new point of breakage every time a vendor updates their UI. Most of these portals were never designed to be queried programmatically—they render HTML for a buyer to read, not JSON for a system to consume. The portal already does the job a person needs; what's missing is a reliable way to run it on procurement's behalf and get a structured answer back instead of a page someone has to open and read.

One Identity Per Vendor Portal

That starts as a login problem before it's a data problem. Each vendor portal gets its own identity—credentials and session state created once and referenced by ID for every check afterward:

const vendorIdentity = await anchorClient.identities.create({
  source: 'https://supplier-portal.acmeparts.com',
  name: 'Procurement - Acme Parts Vendor Portal',
  credentials: [{
    type: 'username_password',
    username: process.env.ACME_PORTAL_USER,
    password: process.env.ACME_PORTAL_PASS,
  }],
});

const session = await anchorClient.sessions.create({
  session: { tags: ['procurement', 'acme-parts', 'po-status'] },
  identities: [{ id: vendorIdentity.id }],
});
// Session opens already authenticated against the vendor's portal.

Procurement never touches or re-enters a vendor's credentials directly, and the session's tags mean any single check can be traced back later—which vendor, which purchase order, which run—for an audit or a supplier dispute.

Checking Every Vendor Without Opening Every Tab

A weekly status sweep rarely stops at one vendor. The same check—open orders, outstanding invoices, expiring certifications—needs to run against every active supplier portal, and going one at a time is the slow part. Since every vendor has its own identity, the fan-out is a set of concurrent, independently authenticated sessions:

const vendors = [
  { name: 'acme-parts', identityId: acmeIdentity.id },
  { name: 'northline-logistics', identityId: northlineIdentity.id },
  { name: 'delta-fasteners', identityId: deltaIdentity.id },
];

const sessions = await Promise.all(vendors.map(v =>
  anchorClient.sessions.create({
    session: { tags: ['procurement', v.name, 'weekly-sweep'] },
    identities: [{ id: v.identityId }],
  })
));

Turning Portal Pages Into Structured Records

The result a buyer actually wants isn't a browser tab—it's a row in a spreadsheet or a field in the ERP. agent.task() can run against each authenticated session with an output schema, so "check open order status" comes back as data instead of a rendered page:

const results = await Promise.all(sessions.map((session, i) =>
  anchorClient.agent.task(
    'Open the order status page and return the status and expected ship date for all open purchase orders',
    { taskOptions: { sessionId: session.id, outputSchema: zodToJsonSchema(OrderStatusSchema) } }
  ).then(r => ({ vendor: vendors[i].name, ...r }))
));
// [{ vendor: "acme-parts", status: "Shipped", shipDate: "2026-07-25" },
//  { vendor: "northline-logistics", status: "Processing", shipDate: null },
//  { vendor: "delta-fasteners", status: "Backordered", shipDate: "2026-08-02" }]

Three portals, three logins, three inconsistent layouts—one array back, ready to sync into whatever system procurement already tracks orders in.

Coverage Without a New Integration Per Vendor

None of this asks a vendor to change anything or expose an API they don't have. It's the same portal a buyer already has standing access to, run under an identity that a security review can trace and a session that a compliance check can replay if a shipment or an invoice is later disputed. If your procurement or supply chain team is manually checking a rotating list of vendor portals every week, that's exactly the gap Anchor Browser is built to close—get started with the docs or reach out to see it running against your own vendor list.