Who do I contact at MultiOn to set up a production pilot (security review, proxy requirements, concurrency testing, support)?

Most teams realize they’re ready for a production pilot the moment “let’s try MultiOn” turns into “we need security, proxies, and SLAs.” At that point, you don’t want a generic contact form; you want a clear path to an engineering-aware team that can talk sessions, bot protection, and concurrency limits.

Below is how to route that conversation at MultiOn, what information to include, and how to frame your pilot so you get meaningful answers on security review, proxy requirements, concurrency testing, and production support.

Quick Answer: For a production pilot with security, proxy, and scale requirements, contact the MultiOn team via the main site (https://multion.ai) using the “Get in touch” / “Contact” path or sales/partnership email, and explicitly flag that you’re planning a production pilot with:

Security review

Native proxy needs / bot protection

High-concurrency testing

Formal support expectations

From there, you’ll typically be routed to:

An account / solutions owner for commercial + pilot scoping
A technical contact who can go deep on Agent API (V1 Beta), Retrieve, Sessions + Step mode, and proxy setup

At-a-Glance: Who to Contact for Each Pilot Dimension

Need	Who You’re Actually Looking For	What to Ask For	Why It Matters
Security review	Security / platform owner via sales or partnerships	Security package, data flows, auth model, logging, compliance posture	Unblocks your internal security & risk review
Proxy & bot protection	Technical contact / solutions engineer	Native proxy support details, IP ranges, bot protection strategies	Ensures agents can operate on real, protected sites
Concurrency & load	Engineering / platform support	Concurrency limits, parallel sessions, rate limits, “402 Payment Required” behavior	Proves you can scale to your real traffic profile
Production support	Account owner + support	SLAs, incident process, escalation paths, sandbox vs prod	Defines who picks up the phone when something breaks

How to Reach the Right People at MultiOn

Right now, MultiOn doesn’t expose a public “security@” or “sales@” address in the docs the way some legacy vendors do. Instead, use the primary website contact route and clearly label your request as a production pilot.

1. Use the main contact path from the MultiOn site

Go to https://multion.ai
Use the contact / get in touch / request access path (this may appear as “Contact,” “Get access,” or similar).
In the message field, be explicit that this is a production pilot request, not a casual sandbox test.

Subject / first line suggestion:

“Request: Production pilot for browser-operating agents (security review, proxies, concurrency, support)”

This will get routed internally to the right mix of:

Account / business owner – to coordinate timelines, pilot scope, and budget.
Technical owner – to work through Agent API (V1 Beta), Retrieve, Sessions + Step mode, security questions, and proxy strategy.

2. If you already have an API key or prior contact

If your team has:

An existing API key, or
Prior contact from a MultiOn demo / trial / event, or
An email from someone at MultiOn (e.g., from onboarding),

you’ll move faster by replying directly to that thread with a clear production-pilot proposal (template below). That’s often how you get introduced to the solutions / platform engineer who can talk about session_id, “secure remote sessions,” and native proxy support in detail.

What to Include in Your Production Pilot Request

If you want a serious response instead of a generic “we’ll get back to you,” walk in with real constraints. Here’s the checklist I’d send as a former automation engineer.

1. Describe your primary use case in API terms

Frame your pilot as intent → endpoint → output, not “we want to try some AI.”

Example description:

Goal: Automate end-to-end checkout on Amazon using a browser-operating agent.
Surface: POST https://api.multion.ai/v1/web/browse
Pattern: Start a session with cmd + url, then continue using session_id and Step mode until order confirmation.
Outputs: Final state confirmation + logs of actions; optionally, structured data using Retrieve for catalog extraction.

Or for research / extraction:

Goal: Turn a dynamic H&M category page into structured product JSON.
Surface: Retrieve API.
Pattern: renderJs: true, scrollToBottom: true, maxItems: 200 to handle lazy-loaded content.
Outputs: “JSON arrays of objects” with fields like name, price, colors, productUrl, imageUrls.

Include this in your initial message so the MultiOn team knows you speak their language.

2. Spell out your security review requirements

Ask for (and expect) concrete artifacts, not marketing.

In your message, list:

Data handling & flows
- Where browser sessions run (e.g., “secure remote sessions” infrastructure)
- How X_MULTION_API_KEY is handled and authenticated
- Whether session data is stored, for how long, and under what controls
Access & isolation
- How tenant isolation works (per API key / account)
- How “secure remote sessions” are scoped per session_id
- Any admin controls for revoking keys or terminating sessions
Logging & monitoring
- What is logged for POST /v1/web/browse and Retrieve calls
- Options to minimize data in logs for sensitive flows (e.g., KYC, payments)
Compliance
- Whatever your org requires (e.g., SOC 2, ISO, data residency constraints)

How to phrase it in your contact:

“We need to run this through our security review. Please connect us with someone who can walk through data flows for POST https://api.multion.ai/v1/web/browse, session_id behavior, secure remote sessions, logging, and any available compliance documentation.”

3. Detail your proxy and bot-protection needs

If your workflows touch login-heavy or bot-protected sites, don’t hand-wave this. Ask for specifics on native proxy support and how MultiOn handles “tricky bot protection.”

Include:

Target domains: e.g., Amazon checkout, X posting, H&M catalog
Likely blockers: WAFs, bot frameworks, geofencing, rate limits
Your constraints: Required regions, IP whitelisting policies, any legal/compliance limits on proxy use

Sample wording:

“Our flows will target login-protected and bot-protected sites. We need to understand MultiOn’s native proxy support (regions, IP ranges, rotation strategy) and how those proxies integrate with secure remote sessions during high-concurrency runs.”

This is what will pull in someone who can talk operationally about:

How agents route through proxies
How they maintain session continuity with session_id even as requests fan out
What you can and can’t control from your side

4. Set expectations for concurrency testing

Your goal in the pilot is to break things in a controlled way, not in production at 3am. Ask for:

Concurrency limits:
- Max concurrent sessions per account
- Recommended ceiling for pilot vs production
- How to increase limits as you go from pilot → rollout
Parallel agent behavior:
- Whether “millions of concurrent AI Agents” is theoretical or contractually supported for your use case
- How parallel runs interact with native proxy support and session continuity
Error & throttling behavior:
- Rate limiting responses
- The meaning of “402 Payment Required” and how billing / quota exhaustion is signaled in responses

Example ask:

“We plan to test up to 5k–10k concurrent browser sessions hitting dynamic, JS-heavy pages via POST /v1/web/browse and Retrieve. Can we review documented concurrency limits, throttling behavior, and how ‘402 Payment Required’ is surfaced so our client handles quota failures cleanly?”

5. Clarify support, SLAs, and incident handling

A production pilot is where you find out how the vendor behaves when something breaks.

Ask for:

Support channels: Email / ticket system / Slack / something else
Response and resolution targets: For pilot vs GA production
Incident process: How outages, degraded performance, or proxy issues are communicated
Environments: Whether you get distinct “sandbox” and “production” API surfaces, and how they differ

Suggested language:

“For this pilot, we’ll be integrating MultiOn into a user-facing application. We need to understand support channels, response times, and how incidents (e.g., degraded secure remote sessions or proxy failures) are communicated during the pilot and in production.”

Example Email / Form Submission Template

You can almost copy-paste this into the contact form on https://multion.ai or send it to your existing MultiOn contact:

Subject: Production pilot request – browser-operating agents with security review & concurrency testing

Hi MultiOn team,

We’d like to set up a production pilot using MultiOn’s Agent API (V1 Beta), Retrieve, Sessions + Step mode, and native proxy support. Our goal is to validate MultiOn for real user flows and then scale to production.

Use cases:

Amazon: end-to-end multi-step purchase flows using POST https://api.multion.ai/v1/web/browse with cmd + url and session_id continuation

H&M: dynamic catalog extraction to “JSON arrays of objects” via Retrieve with renderJs, scrollToBottom, and maxItems

What we need for the pilot:

Security review – data flows for secure remote sessions, X_MULTION_API_KEY handling, logging, and any available compliance documentation.

Proxy / bot protection strategy – details on native proxy support, IP ranges/regions, and behavior on bot-protected sites.

Concurrency testing – documented concurrency limits, recommended pilot scale, throttling behavior, and how “402 Payment Required” is surfaced to our client.

Support expectations – support channels, typical response times, and incident communication for pilot vs production.

Our target timeline is:

Pilot design & security review: [date range]

Load/concurrency tests: [date range]

Go/no-go decision for production: [date]

Could you connect us with the appropriate technical and account contacts to scope this pilot?

Thanks,
[Your name]
[Your role / team]
[Company]

How MultiOn Typically Fits Into a Production Pilot

To make your conversations with MultiOn more productive, it helps to know how they expect you to build.

A common pilot shape looks like:

Install and basic wiring
- npm install multion or equivalent in your stack.
- Store X_MULTION_API_KEY in your secrets manager.
- Stand up a small backend service that:
  - Calls POST https://api.multion.ai/v1/web/browse with cmd + url.
  - Stores and reuses session_id for multi-step flows (Sessions + Step mode).
  - Uses Retrieve for structured extraction when needed.
One realistic, end-to-end task
- Example: Complete an Amazon order for a test item.
- Your service:
  - Starts the session (navigate to product).
  - Steps through add-to-cart → checkout → place order with session_id continuity.
  - Validates final state (order confirmation) and logs the full flow.
Scale up with concurrency
- Spin up many parallel agents:
  - Multiple session_ids, each driving its own secure remote session.
- Monitor:
  - Success rate.
  - Latency under load.
  - Proxy behavior / bot responses.
  - Any 4xx/5xx patterns and “402 Payment Required” events.
Operational hardening
- Decide retry policies.
- Instrument logging and metrics around session failures and timeouts.
- Align on SLAs and escalation path with the MultiOn team.

Walking into the pilot conversations with this shape in mind makes it easier to align with how MultiOn thinks about “millions of concurrent AI Agents ready to run” as a backend capability.

Final Verdict

To set up a serious production pilot with MultiOn—one that covers security review, proxy requirements, concurrency testing, and support—you should:

Initiate contact via the main MultiOn site (https://multion.ai) and clearly label your request as a production pilot.
Ask to be connected to both an account owner and a technical contact, and use precise language around the Agent API (V1 Beta), Retrieve, Sessions + Step mode, secure remote sessions, and native proxy support.
Include concrete details on your target flows, security constraints, proxy/bot-protection needs, and concurrency goals so you get routed to the right people from day one.

Once you have that line of communication open, you can co-design a pilot that actually de-risks production: real user flows, real load, and clear answers on how MultiOn behaves under the operational pressure your product will generate.

Next Step

Get Started