“Get this vendor's invoice” is not enough information to select an adapter. One customer may need structured data through an approved integration. Another may need a saved supplier document. A third may still use a desktop application that a browser worker cannot operate.

Put the requested deliverable, account scope and verified interface into the routing decision. The vendor name identifies the system; it does not establish what your worker can do there.

I work on BrowserAct's content and workflow documentation. This AI-assisted article proposes a small routing model using synthetic fixtures. No Worldpac account, OMS request, speedDIAL download or BrowserAct collector was tested. The Python function is an internal design example, not a vendor SDK.

A useful split in the Worldpac guide

Our guide distinguishes browser-based speedDIAL 2.0 from Classic desktop instructions. It also describes OMS invoiceList and invoiceDetails as invoice-data capabilities. Those facts support three separate questions:

  • Does this customer have approved access to the data integration?
  • Has this worker's actual browser interface been verified?
  • Does the verified route deliver the requested document, if a file is required?

An invoice-data endpoint's existence does not answer the last question. A browser login does not answer the first. A Classic screenshot does not answer the second for a 2.0 web worker.

Avoid defining one adapter as “Worldpac supported” and letting every job inherit all three claims. Capabilities should describe a specific account and execution environment, with evidence for each output type.

Treat unknown capability as a real result

The router below returns a route and a reason. It has no endpoint URLs, credentials or browser selectors. It does not try one access path after another until something responds. Instead, it asks whether a previously approved capability matches the request.

The capability record belongs to an account. A route verified for one shop must not silently authorize another account's collection. In production, those records need trustworthy provenance and a defined expiration policy; an arbitrary request payload must not be able to grant itself approval.

def select_route(request, capability): if not request.get("account_ref"): return "review", "account_missing" if request["account_ref"] != capability.get("account_ref"): return "review", "account_mismatch" output = request.get("output") if output == "invoice_data": if capability.get("oms_production_approved") is True: return "oms_data", "approved_data_route" return "review", "data_access_unverified" if output != "supplier_original_file": return "review", "unsupported_output" if capability.get("interface") == "classic_desktop": return "review", "desktop_worker_required" if capability.get("interface") != "speeddial_2_web": return "review", "interface_unverified" if capability.get("original_file_route_verified") is not True: return "review", "original_file_route_unverified" if capability.get("browser_collection_authorized") is not True: return "review", "browser_access_unverified" return "browser_document", "verified_document_route"

These are our own descriptive flags. They are not Worldpac API response fields. In particular, the example does not claim that an original-file route exists in every speedDIAL account. The default result for an unverified route is review.

The data branch is deliberately independent of the user interface. A customer using Classic could also have an approved integration; the function should not reject data access merely because the shop's manual interface is a desktop client. Conversely, approval for data access must not authorize a document worker by implication.

Route selection is not task completion

Selecting oms_data only chooses the next worker. It does not claim that a request has succeeded. That worker still needs to validate response identity and the expected output contract. Authorization failures or expired access should become explicit outcomes rather than an automatic switch to a different identity or collection mechanism.

Selecting browser_document is similarly a prerequisite. The worker must collect and verify the actual file, retain its source and account context, and report missing records. A successful view or a printed page should not be called a supplier-original download without evidence for that classification.

When a request needs both structured data and a document, split it into two required outputs. Route each separately and aggregate their verified results afterward. This avoids making a data importer responsible for proving something about a file it never received.

Keep capability evidence maintainable

Attach the review date, environment and account reference to the capability record. Revisit it when the interface changes or an approved integration's scope changes. Do not reuse historical UI verification indefinitely just because its vendor label still matches.

A review result should name the missing dependency: approval, interface identification or evidence for the original file. That gives the operator a concrete next step and prevents a scheduler from repeatedly sending the same impossible job to a browser worker.

The accompanying local checks use invented account references and flags. They verify routing for approved data, missing approval, Classic document work, unknown interface, an unverified file path, missing browser authorization and a verified synthetic document capability. They do not verify Worldpac availability or product behavior.

Portal context and limits: Find Worldpac invoices in speedDIAL 2.0. The source guide supplies the interface and data-versus-file distinctions. The capability registry and routing code are proposed application architecture.