Connect an Agent to
M2M Market.

Sign in to the Agent dashboard, create or connect the production Agent wallet, fund it, and make sure the wallet has enough available balance for paid requests. Configure the spending policy before connecting application code.

Before integration, verify

• Your Agent account is active.
• The wallet is funded and available balance is positive.
• A delegated authorization is active for the Agent signer.
• Your per-query limit is high enough for the services the Agent may buy.
• Any reputation or provider-selection requirements are intentional.

Open Agent → Connect Agent in the dashboard. Choose the delegated authorization to bind, give the credential a descriptive application name, select its expiry, and create it.

The connection token is displayed once. Copy it immediately and store it in your application secret manager or environment configuration. Do not commit it to source control. If a token is exposed or the application is retired, revoke it from the dashboard and issue a new one.

The SDK exposes a connection test so an application can verify that its token and Agent are ready before attempting a paid request.

client = M2MConnectionClient.from_environment()
readiness = client.test_connection()
print(readiness)

The readiness response is designed to surface whether Agent details, spending policy, delegated authorization and funding are ready, including the currently available M2M balance. Run this during deployment checks and after credential or policy changes.

The installable clients read the API URL and connection token from environment variables.

export M2M_API_BASE_URL="https://YOUR_M2M_API_BASE_URL"
export M2M_CONNECTION_TOKEN="m2m_live_conn-..."
export M2M_REQUEST_TIMEOUT_SECONDS="30"

Use the API base URL shown by your M2M dashboard/runtime configuration. Keep the connection token server-side; do not expose it in browser JavaScript or public client bundles.

Use the standard client when your Agent runtime is Python. The execution policy in code can further narrow a request, while the dashboard authorization remains the upper security boundary.

# Terminal
pip install m2m-market
export M2M_API_BASE_URL="https://YOUR_M2M_API_BASE_URL"
export M2M_CONNECTION_TOKEN="m2m_live_conn-..."

# agent.py
from m2m_market import ConnectionExecutionPolicy, M2MConnectionClient

client = M2MConnectionClient.from_environment()
result = client.execute_task(
    category="traffic-data",
    payload={"origin": "Nairobi CBD", "destination": "JKIA"},
    policy=ConnectionExecutionPolicy(
        maximum_price_m2m="0.05",
        minimum_reputation=80,
        maximum_attempts=2,
    ),
)
print(result["response"])

execute_task performs the complete task flow, including permitted provider failover attempts, status waiting and successful settlement completion.

For JavaScript or TypeScript Agent runtimes, install the same m2m-market package from npm and create the client from environment configuration.

# Terminal
npm install m2m-market
export M2M_API_BASE_URL="https://YOUR_M2M_API_BASE_URL"
export M2M_CONNECTION_TOKEN="m2m_live_conn-..."

// agent.mjs
import { M2MConnectionClient } from "m2m-market";

const client = M2MConnectionClient.fromEnvironment();
const result = await client.executeTask({
  category: "traffic-data",
  payload: { origin: "Nairobi CBD", destination: "JKIA" },
  maximumPriceM2m: "0.05",
  minimumReputation: 80,
  maximumAttempts: 2,
});
console.log(result.response);

Keep M2M_CONNECTION_TOKEN in your server/runtime secret store rather than shipping it to a frontend.

Any language capable of HTTPS can integrate directly with the connection execution endpoint. Send the connection credential as a Bearer token and the service request as JSON.

export M2M_CONNECTION_TOKEN="m2m_live_conn-..."

curl -X POST "https://YOUR_M2M_API_BASE_URL/connect/execute" \
  -H "Authorization: Bearer $M2M_CONNECTION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "category": "traffic-data",
    "payload": {
      "origin": "Nairobi CBD",
      "destination": "JKIA"
    },
    "maximum_price_m2m": "0.05",
    "minimum_reputation": 80,
    "maximum_attempts": 2,
    "response_format": "JSON"
  }'

If you integrate directly, preserve the task/query IDs returned by the API so your application can correlate status, retries and settlement records.

The OpenAI adapter presents M2M Market as a tool the model can call when it decides an external paid capability is required.

# Terminal
pip install "m2m-market[openai]"

from m2m_market import (
    M2MConnectionClient,
    M2MToolAdapter,
    openai_tool_definition,
)

client = M2MConnectionClient.from_environment()
adapter = M2MToolAdapter(client)
tools = [openai_tool_definition()]

# Supply tools to your model. When it calls
# purchase_external_service:
result_json = adapter.invoke_json(tool_call.function.arguments)

Pass the generated tool definition to your model/tool-calling configuration. When the model requests purchase_external_service, pass the tool arguments to the adapter. M2M then applies the bound credential and spending controls.

The adapter converts M2M into a LangChain-compatible tool that can participate in a tool-calling Agent alongside your other tools.

# Terminal
pip install "m2m-market[langchain]"

from m2m_market import M2MConnectionClient, M2MToolAdapter

client = M2MConnectionClient.from_environment()
m2m_tool = M2MToolAdapter(client).as_langchain_tool()

agent = create_tool_calling_agent(model, [m2m_tool], prompt)
executor = AgentExecutor(agent=agent, tools=[m2m_tool])

Your normal LangChain prompt and model remain in control of tool selection; M2M policy remains in control of whether the resulting purchase is allowed.

Install the CrewAI extra and attach the generated M2M tool to the CrewAI Agent that needs external services.

# Terminal
pip install "m2m-market[crewai]"

from m2m_market import M2MConnectionClient, M2MToolAdapter

client = M2MConnectionClient.from_environment()
m2m_tool = M2MToolAdapter(client).as_crewai_tool()

agent = Agent(
    role="Service purchasing Agent",
    goal="Obtain trusted external API results",
    tools=[m2m_tool],
)

The CrewAI role and goal determine when the Agent wants the capability. M2M still applies the bound connection credential and spending controls before execution.

The AutoGen adapter exposes the M2M purchase operation as a function that can be registered with your AutoGen Agent.

# Terminal
pip install "m2m-market[autogen]"

from m2m_market import M2MConnectionClient, M2MToolAdapter

client = M2MConnectionClient.from_environment()
purchase_external_service = M2MToolAdapter(
    client
).as_autogen_function()

# Register purchase_external_service with your AutoGen Agent.

Register the returned function using your AutoGen version's normal function/tool registration mechanism.

Execution request

• category — required provider capability.
• payload — provider-specific JSON input.
• maximum_price_m2m — optional task ceiling that can only tighten dashboard policy.
• minimum_reputation — optional provider reputation floor.
• maximum_attempts — optional provider failover count; SDK execution permits 1–5 attempts.
• response_format — defaults to JSON.
• task_id, attempt_number and excluded candidates are used to maintain multi-attempt task continuity.

Status and completion

The Python client exposes get_query_status(query_id), get_task_status(task_id) and wait_for_query(query_id). The current terminal query states handled by the SDK are settled and released. A successfully completed execute_task result includes task context, provider/service identifiers, lifecycle state, attempt history and payment receipt data when available.

Treat request-level values such as maximum_price_m2m and minimum_reputation as narrower task rules. They cannot grant authority that the dashboard policy does not already permit. The active delegated authorization remains authoritative.

Recommended production pattern

• Use the smallest practical per-query ceiling.
• Issue separate credentials for separate Agent applications.
• Use meaningful credential expiry instead of permanent tokens.
• Revoke unused or compromised credentials immediately.
• Keep owner recovery authority separate from Agent execution secrets.

1. Authenticate: M2M validates the connection token and bound delegated authorization.
2. Discover: the requested category is matched to eligible provider services.
3. Authorize: price, reputation, attempt and spending constraints are checked.
4. Dispatch: the request is sent to the selected provider.
5. Respond: the provider result returns to the Agent.
6. Settle: a successful interaction moves through M2M settlement and becomes observable in transaction history.

When a provider attempt does not complete the task, the SDK can obtain task status, apply required exclusions, advance to the next permitted attempt and avoid blindly retrying the same candidate.

Provider onboarding is the other side of these integrations. Register a provider profile, publish the service category and endpoint, define the price, keep the endpoint healthy, and monitor requests, responses, reputation and earnings from the Provider dashboard.

Explore the Marketplace model →

Connection rejected

Check that the token is correct, active, unexpired and not revoked. Confirm it is bound to an active delegated authorization. The SDK also validates that the API base URL uses HTTPS and that connection tokens have the expected m2m_live_conn- prefix.

Request blocked before provider execution

Check wallet funding, per-query allowance, requested price ceiling, minimum reputation and provider-selection constraints.

No eligible provider

Confirm the requested category matches a currently active provider capability and that policy filters are not excluding every candidate.

Provider execution failed

Inspect the task/query status and attempt history. Respect the configured maximum attempts rather than retrying indefinitely.

Long-running query

The Python SDK waits for query completion with a configurable timeout and polling interval. Treat timeout as an unresolved state to inspect, not proof that settlement failed.

Response succeeded but settlement is unclear

Use the dashboard transaction and live-network surfaces to verify the settlement stage separately from the provider response stage.