Start with a URL
Use a live or local authorized URL and a concrete claim such as a visible receipt or completed onboarding step.
A web app can look healthy while a callback, redirect, verification code, or receipt path is broken. Molar combines browser exploration, goal based execution, and integration fixtures to put those transitions inside the test conversation.
Use a live or local authorized URL and a concrete claim such as a visible receipt or completed onboarding step.
Read bounded accessibility observations and structured page context before asking the agent to change state.
A run can retain screenshots, trace identifiers, and artifact references for review and later diagnosis.
Focus on journeys where the browser, backend, and third party must agree. That is where a screenshot alone cannot establish correctness.
- status: pending + status: confirmed + receipt: attachedcommit 8e4c · 3 files changed
preview.acme.testSignup and verificationPassed
Invite a teammatePassed
Payment confirmationFailed
The unified CLI supports local browser verification and hosted fallback. Hosted runs use scoped credentials and target authorization, with private beta limits applying.
Talk through your use casepayment_intent.succeededOpen checkoutScreenshot captured200
Confirm paymentPOST /webhooks/payment200
Receive receiptTest inbox matchedready
Have a specific workflow in mind?
Let’s talk it through
Yes. The verify command accepts a natural language assertion, such as an order confirmation number being shown, against a URL or prior task.
Molar can export or produce Playwright oriented artifacts in supported workflows, while Playwright remains a useful direct test tool.
Use an authorized saved profile or login credential reference. The system keeps login state origin bound and scopes access.
Choose a concrete workflow. We’ll help you get the right setup for your application.