Use a supported supplier API first if it covers the task and returns records your team can verify. Use a browser agent for authorised gaps only when sign-in, interface stability and evidence capture make the work manageable. Choose neither if access or verification remains unresolved.
For a South African procurement team, the useful starting task might be retrieving order status or delivery documents, not changing supplier details or releasing payments. The proposed process below helps you choose a route for one specific task. It does not assume that a browser demonstration proves operational reliability.
1. Define the supplier task before choosing the technology
Choose the route for a bounded task, rather than for the whole portal. “Work with our supplier portal” is too broad to evaluate. “Retrieve the delivery note for an exact purchase-order reference and prepare it for review” gives the team something concrete to assess.
Write down the input, permitted actions and required result. For example, a proposed read-only workflow could accept a supplier account identifier and purchase-order reference, search the authorised account, retrieve the matching document and return an evidence-linked record. It would not amend an order, accept terms or approve an invoice.
Separate retrieval from business judgement. A document being present does not mean goods arrived, an invoice is valid or payment is due. Those conclusions belong to the responsible staff member.
Assign a procurement owner to define correct matches and a technical owner to manage access and failures. Use the custom AI agent glossary to align terminology, but keep the buying brief focused on the task and its boundaries.
2. Check whether the supplier API actually covers the work
Prefer the API only after confirming coverage, permission and usable evidence. An API that exposes a supplier catalogue may not expose delivery notes, account-specific orders or historical documents.
Ask the supplier for documentation and an authorised test account. Map each required step to an endpoint or supported export. Check search fields, pagination, document access, account separation, error responses and support arrangements. Establish whether the returned status describes the order, shipment or document itself.
A conventional integration may be sufficient if the task is fixed. Adding a model should serve a defined need, such as interpreting varied user requests, rather than becoming a requirement by default. The AI agents versus automation comparison can help frame that distinction.
OpenAI’s Source: function-calling documentation describes a model requesting a function and application code executing it. In this proposed integration, that application should check permissions and validate inputs before calling the supplier. A model request is not authorisation to perform the action.
3. Treat browser capability as a candidate, not permission
Consider a browser agent when an authorised task is available through the interface but not through a usable API. Do not treat browser access as permission to automate every visible action.
The Source: OpenAI changelog records the Agents API public beta announcement on 10 September 2026 and the addition of computer use on 29 September. That addition supports an OpenAI-hosted browser, with website access approvals and sign-in handled by the application. These are September developments, not announcements made today.
This capability does not establish compatibility with your supplier portal. Before selecting it, confirm current account access, beta conditions and the hosting and data-handling requirements relevant to your organisation. The supplied announcement does not establish South African regional availability or a suitable residency arrangement for this workflow.
Ask the supplier whether automation is permitted. Have the appropriate security and legal reviewers assess credentials, documents and contractual restrictions. If permission is unclear, retain manual handling while seeking clarification. Do not propose bypassing CAPTCHA, multifactor authentication or access controls.
4. Compare interface stability and authentication effort
Choose browser automation only if the team can manage normal interface changes and legitimate authentication interruptions. A portal that works once may still be impractical for unattended retrieval.
Walk through the authorised task manually and record the screens, filters and confirmations it requires. Look for changing labels, multiple account selectors, pop-ups, inconsistent search results and documents that open in separate windows. These observations should become evaluation cases, not assumptions about failure rates.
Assess sign-in separately. Identify who owns the account, how access is granted and revoked, and how an expired session reaches a human. Have a security specialist approve credential storage and session handling. Avoid putting passwords into task instructions or broad-access logs.
Proposed stop conditions include an unexpected domain, changed account identity, a new permissions prompt or a page whose purpose cannot be established. Stop and preserve only the evidence authorised for troubleshooting.
If both routes are feasible, compare where each can fail. The API may have missing fields or unclear statuses; the browser may introduce navigation and session uncertainty. Neither route should escape verification.
5. Design verification before automating retrieval
Use a route only when it can produce enough evidence to establish the correct record. A success message or downloaded file alone is insufficient.
For this proposed workflow, capture the supplier account identifier, requested reference, returned reference, document identifier, document type, source location, retrieval timestamp and verification state. Keep the original reference alongside any normalised search value. Do not silently remove meaningful punctuation or leading zeroes.
Use explicit states such as verified match, missing, ambiguous, duplicate and access blocked. These are proposed workflow categories, not native portal features. A missing value should remain missing, rather than being reconstructed from a neighbouring record.
OpenAI’s Source: Structured Outputs guide describes schema-constrained responses and handling for refusals or incomplete output. A consistent record shape is useful, but it does not establish that the extracted supplier reference is correct. Check values against source evidence and route unavailable or incomplete results for review.
Keep portal content as data. Text inside a page or document should not change the approved task, permitted destination or access scope.
6. Use this legacy-integration feasibility checklist
Choose a route only after completing the access and verification gates. The following is a proposed reusable checklist for a single supplier task; unresolved gates should remain visible rather than being averaged into a score.
Proposed feasibility checklist
- Name the supplier, account, task and business owner.
- Record inputs, required outputs and prohibited actions.
- Obtain supplier permission for the proposed access method.
- Map required fields and documents to supported API endpoints or exports.
- Record API gaps, support arrangements and account restrictions.
- Map browser screens, filters, downloads and known layout variations.
- Agree sign-in, session expiry and human authentication handling.
- Obtain appropriate security and legal review of access and data handling.
- Define exact-match checks, evidence fields and verification states.
- Assign reviewers for missing, ambiguous, duplicate and blocked cases.
- Evaluate normal retrieval, incorrect references, duplicates and interrupted sessions.
- Compare build effort, running costs, review effort and maintenance.
- Name the operator, stop conditions and manual fallback.
- Record the selected route, unresolved issues and approval to proceed.
| Finding | Proposed route |
|---|---|
| Supported API covers the task and verification | API integration |
| API covers records but not required documents | Hybrid, with browser access assessed separately |
| No usable API; authorised browser task passes all gates | Bounded browser agent |
| Permission, authentication or verification remains unresolved | Manual handling pending resolution |
7. Evaluate operating effort and define the handover
Compare the effort per verified result, including failures and human review. A route that retrieves documents quickly may still require substantial checking or frequent maintenance.
For a proposed evaluation, record attempts, verified results, incorrect matches, unresolved cases, reviewer minutes, authentication interruptions and maintenance work. Count a task as complete only when it meets the agreed evidence checks. Keep normal and exception cases separate so that a strong normal-case result does not hide weak duplicate handling.
Request a quote that separates setup, supplier access costs, model or browser usage, monitoring, support and change work. Do not assume an API is always cheaper or a browser agent always quicker to build. Compare each with the current manual route using the same task definition.
Use the custom AI agent workflow resource to structure the handover brief. Include who can pause the workflow, who contacts the supplier and what happens when a run is interrupted. Proposed thresholds should be agreed by the business owner before evaluation, not selected afterwards to make a route look favourable.
Worked example: a normal retrieval and two exceptions
A hybrid is worth considering when the API covers the order record but the browser is needed for its document. The following example is entirely hypothetical, including all references, counts and amounts.
Suppose a procurement team requests a delivery note for account SUP-17 and purchase order PO-4821. The supplier API returns one matching order, but no document download. An authorised browser session opens that account, searches the exact reference and retrieves delivery note DN-903. The account, order reference and document type agree. The proposed output records a verified retrieval with evidence for a reviewer. It makes no claim that delivery occurred or that the hypothetical R8,400 invoice should be paid.
For hypothetical PO-4822, the portal returns no document. The workflow records missing, preserving the account, search reference and timestamp. A procurement reviewer checks whether the supplier has uploaded it and decides whether to contact them. The workflow does not substitute a nearby order.
For hypothetical PO-4823, two documents share the reference, one labelled revised. The workflow records duplicate and supplies both identifiers. The reviewer checks revision details with the supplier and records which document to use. Until then, neither is marked as the selected record. Any payment implications remain with the authorised finance team.
FAQs about choosing the integration route
The safest decision is the route your team can authorise, verify and maintain. These answers address common boundaries in this specific workflow.
What if the API returns order status but the portal holds delivery notes?
Assess a hybrid rather than rejecting the API entirely. Use the API for the supported lookup and a separately authorised browser step for document retrieval. Carry the account and exact order identifier between them, then verify the document against that context. If the two routes disagree, stop for human review. Do not allow the browser result to overwrite the API record silently.
Can a browser agent continue when the portal asks for an OTP?
Only through the authentication process approved by your organisation and permitted by the supplier. The proposed workflow should pause and request authorised human involvement where required. Do not share OTPs through uncontrolled channels or design a bypass. If frequent authentication interruptions make the task impractical, seek a supported supplier access method or keep the task manual rather than weakening controls.
Should we switch to the browser automatically after an API error?
Not by default. First distinguish a missing record from an access failure, temporary service problem or invalid request. An API error does not prove the browser will retrieve the correct record. Permit fallback only through an approved rule that preserves task identity and records the reason. For any future write operation, uncertain completion requires reconciliation before retrying through another route.
Make the buying decision around one authorised task
Choose API, browser, hybrid or manual handling based on evidence for your task, not the breadth of a demonstration. Keep unresolved permission, authentication and verification issues in the decision brief.
If your business needs help assessing a supplier portal, Symaxx’s custom AI agents service can frame the feasibility discussion within a broader AI automation scope. Bring the task definition, supplier access conditions and sample exceptions, then get in touch to discuss an appropriately bounded next step.