Browser automation for websites without APIs
When a website has no suitable API, browser automation can carry out work through the same pages a person uses. A useful workflow needs more than clicks: it needs the right account, clear input records, a way to handle interruptions, and evidence that the requested change was saved.
By Pine AI · Published
Start with the interface you can rely on
Check whether an official API covers the required operation and whether your application can use it. If it does, an API integration may be the simpler choice. If the operation exists only in a portal, evaluate browser automation against that specific task. Access to a website does not by itself establish permission for every automated action.
For a stable sequence on a site you control, a browser script may be sufficient. A goal-driven agent is another option when the work involves interpreting pages, resolving differences between records or moving between sites and files. Test the approach on the actual workflow; neither a script nor an agent removes the need to check results.
Define a job with a reviewable result
A permit-renewal workflow is a useful example. Supply a record for each property, the permit to renew, the allowed changes and the receipt you expect back. A prompt such as “handle the permits” leaves too much unstated. Specify how to treat missing fields, fees and records that do not match.
In Pine Computer, your application can hand the job to the built-in agent, supply files and receive progress and output files. Your product still owns the business rules: which records are eligible, who can authorize a submission and how the result attaches to the correct customer record.
- Supply the exact portal, account context and source records.
- Define the fields that may change and the conditions that require review.
- Arrange a person’s sign-in when the portal requests it.
- Inspect the saved page or confirmation after submitting.
- Return the receipt and unresolved records to your application.
Design for sign-ins and interruptions
A saved sign-in may make the next job easier, but a portal can still ask for a new login or verification code. Pine Computer’s live desktop lets a person take control and hand it back. Treat that interruption as part of the workflow rather than assuming every run will finish unattended.
An inaccessible page, a changed form or a challenge can prevent completion. Do not design around a promise of bypassing bot protection. Decide what evidence to keep and how to return the unresolved record to a person. Keep different customers’ account contexts separate.
The browser’s country can also matter. In Pine’s recorded New York City property-tax example, the portal returned Access Denied to a computer in Singapore. The same program running from the United States retrieved the quarterly bill as a PDF. When diagnosing access, record the portal’s response and check that the computer is in an appropriate supported region for the authorized job.
Verify before retrying
A successful click is not evidence that a renewal, invoice or listing was saved correctly. Read the confirmation, compare key fields with the source record and keep the receipt or output file. If the portal does not expose enough evidence, report that uncertainty for review.
If a run stops after submission, inspect the portal’s current state before repeating the action. Retrying blindly can create duplicate work. Decide in advance how your application identifies an already completed record and which ambiguous outcomes require a person.
Pine’s recorded Odoo example shows why verification needs a business-level condition. Typing the customer’s name into a field did not select the customer from the list, so Confirm failed. The agent corrected the selection. The completion check was the saved order’s Sales Order status; a Quotation did not count. For your portal, write down the equivalent saved state and compare the record identifier, line items and status with the source input.
Reuse a reviewed procedure after it works
In the same order-entry demonstration, Pine writes a draft skill from the completed job. Someone reads and activates that draft before the next order uses it. The useful part of the procedure includes both the necessary customer selection and how to recognize a confirmed order.
Review learned instructions for account-specific details, the intended record type and the evidence of success before activating them. The agent still performs the next job; a skill is guidance for its work, not a recording that replays without the model. Keep credentials outside the procedure and revisit it when the portal changes.
Pilot one portal before expanding
Begin with a small set of records that includes an expired sign-in, a missing field and an already completed item. Count correct results, incorrect results, unresolved records and human interventions separately. Compare the effort of reviewing those results with the original manual workflow.
The examples below show portal work you can design around Pine Computer. They are illustrative. Current SDK contracts live in the developer docs, and Pine Computer remains in private beta.
Explore the workflow
These use cases are examples, not customer case studies.
- Renew permits: Your customer clicks Renew once, and every permit due this quarter is renewed on its own city’s portal.
- Track shipments: A held parcel or a missed delivery shows on its order before the customer writes in to ask.
- Update marketplace listings: Nobody on your user’s team has to retype the spring range into each seller portal.
Product documentation
Use the developer docs for current API contracts and integration instructions.