Use Beeuni as the agent backend for your product

Use the Beeuni API or TypeScript SDK to create agent sessions from your application. Your product handles the interface and its users; Beeuni runs the agent’s tools and returns messages and files.

Imagine a purchasing tool that compares suppliers. A user selects products and approved suppliers; the agent visits their public catalog pages, reads price lists from a connected document service, and builds a comparison sheet. Your application handles sign-in and review, while the Beeuni session gathers the material and runs the comparison.

Define the task your interface submits

List the inputs, permitted actions, output format, and failure cases. For the catalog example, provide approved supplier pages, references to connected catalog documents, and the fields to compare. Require a row per product, its quoted price and currency, and a source reference. Missing dimensions should be marked unknown. The task should not place orders.

• Application responsibilities: authenticate people, decide who may access each task, validate inputs, and present the result.
• Project configuration: choose the agent, model, skills, and authorized tools needed for this type of work.
• Session work: submit the request, follow progress, and inspect the returned messages and output files.

Give the session access to the sources it needs

Configure the project with the browser and connector tools the task needs. For a private document service, connect an account and grant the agent access to the relevant connector. A link in a request does not grant access by itself. Keep the selected account and permitted sources consistent with the customer who submitted the task; the connector guide explains account access.

The agent can then read the selected documents through those tools, visit public product pages, and write a script to reconcile product codes and pack sizes. Ask it to save the retrieved values, source locations, and retrieval times with the result. If a catalog cannot be read or a page requires another login, return that gap to the interface rather than inventing a price.

Keep credentials on your server

The SDK guide shows how to install @beeuni/sdk, create a client, and authenticate requests. Keep the API key on your server, outside browser code.

Decide which Beeuni projects each customer may access. Keep their files and connected accounts separate where needed, and check access on your server before forwarding requests. The authentication guide explains the available sign-in methods.

Show progress and handle reconnects

The SDK supports creating sessions, waiting for readiness, and sending a request. The full example covers receiving events and reading the reply. Use those events to show actual progress. “Opening supplier pages,” “Comparing products,” and “Result ready” should each correspond to work or a state you can observe.

Give each comparison a task record in your application. Store the selected source references, requested columns, Beeuni project and session IDs, and the output location when it becomes available. This record connects your review screen to the work already in progress.

Application task record — illustrative fields, not an SDK payload
app_task_id
approved_source_references
requested_columns
beeuni_project_id
beeuni_session_id
output_reference
review_status

Consider a user who selects three supplier catalogs and then refreshes the page. The refreshed interface looks up the application task and its existing Beeuni session. It reads stored progress and resumes following that work. Creating another session on every page load would duplicate the task.

A connection can also drop before your server receives confirmation of submission. That is an uncertain outcome, not proof that nothing happened. Check the session before sending the request again. If you still cannot determine whether it was accepted, show that uncertainty instead of automatically starting another comparison.

Check the result in your application

For the catalog comparison, check required columns, readable files, source references, and products that could not be matched. Different pack sizes are a common trap: a price per box of twelve cannot be compared directly with a price per item. Preserve the quoted amount and unit, and add a normalized price only when the conversion is supported by the source.

The review screen should let a user open the source behind a price and see unresolved matches. The file can be ready while some rows still need review; keep those states separate in your application.

Let people correct a result without losing its context

Suppose two suppliers use different names for the same chair. The agent leaves them as separate products, and the reviewer recognizes the match. A useful correction includes the two source rows and the intended relationship: “Compare these as the same product, but keep the quoted finish and pack size separate.” Sending only “try again” leaves the agent to guess what was wrong.

Record that correction beside the task and keep the earlier output available. The next result may fix the product match while changing another row. Show the revised comparison and its previous version so the reviewer can check both. Decide which revision the download button serves and record which one was approved.

Approval might publish the comparison to an internal purchasing screen. Sending an order to a supplier is a separate action, with its own permissions and confirmation. Define that boundary in the application before giving the agent access to purchasing tools. Finishing a spreadsheet should not automatically trigger an order.

Decide how much work one request may start

Set practical submission limits, such as the number of catalogs and the work allowed in one request. A comparison of three short price lists is different from reconciling an entire product archive. Show the accepted scope before starting so a person can reduce the request or choose a background job.

Read usage and charge information from the platform where available instead of calculating a final bill from message length. If your product needs a strict spending cap or a cancellation guarantee, verify how the integration enforces it. A countdown or a Stop button alone does not establish that work and charges have stopped.

Try the integration with cases you can check by hand

Keep a small set of catalogs with expected interpretations: a clean price list, an unreadable scan, two currencies, conflicting pack sizes, and a product with no clear match. Use them when changing the model, instructions, or project configuration. Compare the resulting rows and source references, including what the agent leaves unresolved.

Also leave the page during a run, return, and submit a correction after the result appears. Check which output gets downloaded and whether another signed-in person can access the task. The catalog may be interpreted correctly while your application shows the wrong revision or exposes it to the wrong account. Test the agent’s result and the interface around it together.