How AI Agents Request Coverage From OnePark: Instructions, Discovery File and Endpoints

About the author

Reza Azar · Senior Insurance Broker · OnePark Risk

Start with the instructions

OnePark publishes one set of instructions in two forms: an HTML page at /ai-agents/instructions and a Markdown copy at /ai-agents/instructions.md. Both come from the same source; fetch whichever the agent reads more reliably. The instructions cover what OnePark places, where it is licensed, what to collect before submitting, every form field with its requirement level and option values, the JSON keys for direct submission, the request statuses, and the rules an agent is expected to follow. The document states its own last-updated date; re-read it rather than caching it indefinitely.

The discovery file

A machine-readable summary lives at /.well-known/ai-agent.json, under the well-known URI convention so an agent can find it without reading a page. It lists the lines OnePark places, the licensed states, every request field with its requirement level and option values, the full Business Application questionnaire, and both endpoints. Validate a payload against it before sending; the instructions explain each field.

Two doors, both browser forms

An agent can submit a business in two ways. Both reach the same independent brokers, both are ordinary browser forms, and neither requires an MCP server, an API key, or an integration. The how-it-works page describes the choice for a business audience.

• Broker review request at /ai-agents/submit: business basics, goals and context, timeline, who to email, and a permission acknowledgement. Use it when the business wants a broker’s guidance before answering a full questionnaire, or has a fit question first.
• Business Application at /business-application?source=ai_agent: the complete questionnaire, the coverages, the operating states, the authorized representative, and the business’s acknowledgement. Use it when the business can answer every required question now; a question it cannot answer is marked unknown, with a note, instead of guessed. The query string tags the form as opened by an agent.
• An application may cite an earlier request’s reference, which links the two records for the broker; the request’s own email steps continue unchanged.
• Supporting pages such as cyber and technology insurance for agents preselect coverage types on the request form. Preselections stay visible and editable.

The optional JSON endpoints

For agents that prefer to send JSON, each door has an endpoint, and the flow is the same for both: fetch a token, wait briefly, then post one JSON body that includes the token.

• GET /api/ai-agents/token returns a short-lived form token. Wait at least two seconds before using it; it expires after two hours. Send it as formToken in the body.
• POST /api/ai-agents/requests takes the request form’s JSON keys, listed in the instructions, plus formToken. Where a field has options, send the value, never the label; multiple selections are JSON arrays; checkbox keys are true or false; dates are YYYY-MM-DD; permissionAcknowledged must be true. Any key not in the table is rejected.
• POST /api/ai-agents/applications takes the complete Business Application as one JSON body: the coverages, the operating states, the questionnaire sections, the submitter, the authorization, an optional narrative, optional attachments uploaded in advance, an optional earlier request reference, and formToken.
• A 201 carries the reference (AI- for a request, AP- for an application). A request’s 201 also carries a receiptToken that is shown once and never reissued; keep both. An identical retry with the same token replays the original 201 rather than creating a duplicate.
• 400 lists validation errors; 409 means the token was already used with different details, so fetch a new one; 429 means the token is invalid or expired, or that the sender should wait.

What happens after a 201

The endpoints and the browser forms lead to the same place, and from this point on the process is email.

• Request: the follow-up inbox receives a confirmation email with a request-specific link, and the authorized representative receives a separate authorization email with the options to authorize insurance shopping, correct the details, or decline. A broker reads the request as soon as it is saved, before either link is used. Neither link approves an insurance purchase.
• Application: the representative receives an acknowledgement with the application reference. There is no link to click; a broker reads the application and follows up by email, and the representative replies to answer questions or to withdraw an application that was not authorized.
• Every email from OnePark states the current status and the next action. The full status list, from email confirmation needed through coverage bound and policy delivered, is in the instructions.
• With the reference and the receiptToken, an agent can check a request’s current status, re-send a delayed confirmation or authorization email within a per-request allowance, or correct a mistyped inbox, each through its own endpoint described in the instructions. None of these creates a new request; do not file again because an email is delayed.

What is not required

• No MCP server, API key, integration, or developer setup. The browser forms are sufficient on their own, and the JSON endpoints are optional.
• No phone number, phone call, or meeting. The process is forms, email, and secure links for documents, signatures, and payment when needed.
• No email account of the agent’s own. If the agent cannot access email, the routine follow-up inbox is the business contact’s address.

Rules the agent is expected to follow

The instructions ask every agent to work within the capabilities it has and the permission the business gave:

• Submit only with the business’s permission, and acknowledge it on the form.
• Do not invent business facts or underwriting answers. Label estimates as estimates and mark unknowns as unknown; the broker sees every unknown and will ask.
• Fill only the visible fields. The request form contains one visually hidden anti-spam field, and a submission that fills it is refused.
• Keep the reference and reply in the existing conversation. Do not create a duplicate request because an email is delayed, and ask the broker to add coverage to an existing engagement rather than filing again.
• When a step is out of reach, give the business contact the link, the prepared information, the reference, and the exact remaining action. Never claim to have completed a step you could not perform.

What a submission does not do

Submitting a request or an application does not bind coverage and does not guarantee carrier approval or a quote. An AI agent cannot bind coverage. The business’s authorized representative approves any purchase in writing, and OnePark confirms in writing when coverage has been bound. Availability depends on the business, its location, the coverage, and underwriting. If the business is based outside the licensed states listed in the discovery file, say so in the request; OnePark replies by email about whether it can help there or will refer the business elsewhere.

Coverage pages an agent can read first

When the business already knows what it needs, these pages explain each line in plain terms, and an agent can cite them in the request’s context fields:

• Cyber insurance for startups and technology errors and omissions insurance for software and technology businesses.
• D&O insurance for startups and the directors and officers insurance explainer.
• Employment practices liability insurance and the EPLI considerations for technology companies.
• The startup insurance guide, the page on insurance for SaaS companies, and the senior-broker review for technology companies.

For the business side

The companion guide, Your AI Assistant Can Now Request Business Insurance From OnePark, explains the same process for founders, operators, and finance teams: what to give the assistant, what it can and cannot do, and what to expect by email. The AI agents page is the overview, and the instructions are the reference.

Is there an MCP server, API key, or integration?

No. An agent that can browse the web uses the same forms a person does, and the follow-up is email. The JSON endpoints are optional.

Do I have to use the JSON endpoints?

No. The browser forms at /ai-agents/submit and /business-application are sufficient on their own.

How does an agent get a form token?

GET /api/ai-agents/token returns the token. Wait at least two seconds before using it, send it as formToken within two hours, and fetch a new one if the response is 409 or 429.

How does an agent check on a request later?

With the reference and the receiptToken from the 201, through the receipt endpoint in the instructions. It reports the current status and the verification and authorization state; nothing is sent or changed.

Can an agent bind coverage?

No. Submitting a request or an application does not bind coverage and does not guarantee carrier approval or a quote. The business’s authorized representative approves any purchase in writing.