- Each endpoint becomes a Capability (an API Call action)
- Endpoints are grouped into a domain subagent tree (Payments, Customers, Invoices, etc.)
- Your “API docs” are encoded into the agent’s flow step prompts so the agent can sequence calls reliably
1) Choose a subagent tree (example: “Stripe Agent”)
Before importing anything, decide how you want to divide the API into domains. For a Stripe-style API, a common tree is:- Parent: “Stripe Agent”
- Routes requests to the right domain agent
- Produces user-facing answers (and asks clarifying questions when inputs are missing)
- Children (subagents):
- “Stripe Payments Agent” (payments + refunds)
- “Stripe Customers Agent” (customer lookup + updates)
- “Stripe Invoices Agent” (invoice lifecycle)
| Subagent | Example endpoints that become API Actions |
|---|---|
| Stripe Payments Agent | POST /v1/payment_intents, GET /v1/payment_intents/{id}, POST /v1/refunds, GET /v1/charges/{id} |
| Stripe Customers Agent | POST /v1/customers, GET /v1/customers/{id}, GET /v1/customers, POST /v1/customers/{id} |
| Stripe Invoices Agent | GET /v1/invoices, GET /v1/invoices/{id}, POST /v1/invoices, POST /v1/invoices/{id}/finalize |
2) Create the parent agent + domain subagents
Create the parent (“Stripe Agent”)
- Go to Forge > Agents → Create Agent.
- Set:
- Name: “Stripe Agent”
- Description: “Routes requests across Stripe domains and returns user-facing answers.”
- Execution Mode: Reasoning — the parent needs to sequence calls, delegate to domain subagents, and wait on webhooks
- Base URL (optional): default host used by API actions (often your Stripe proxy / gateway)
Create one agent per domain (Payments, Customers, Invoices)
- Go to Forge > Agents → Create Agent (repeat for each domain).
- Keep descriptions crisp (they are used for routing).
Attach subagents under the parent
- Open the parent agent.
- Go to Capabilities.
- Click Add Capability → choose Subagent.
- Add your domain agents (Payments, Customers, Invoices).
3) Capabilities: convert endpoints into API Call actions (OpenAPI → actions)
This is the “endpoint-to-action” step: each selected OpenAPI operation becomes one API Call action.Bulk Import (recommended for “every endpoint becomes an action”)
Do this once per subagent, selecting only the endpoints for that domain:- Open a domain subagent (e.g., “Stripe Payments Agent”).
- Go to Capabilities.
- Click Bulk Import.
- Paste your OpenAPI spec (JSON or YAML).
- Deselect any endpoints that don’t belong to this subagent’s domain.
- Optionally rename action names/descriptions (recommended for readability).
- Click Import.
- Path + query parameters
- JSON request body schema (when present)
- JSON response schemas (per status code, when present)
Single-action Import (good for incremental additions)
- Open the agent.
- Go to Capabilities → Add Capability → API Call.
- In the API action editor, click Import and paste an OpenAPI spec.
- Select the operation to use and import it.
4) Capabilities: add webhook-based lifecycle handling (PaymentIntent example)
Some APIs are inherently asynchronous. For Stripe PaymentIntents, “create” and “final status” are often separated by an event (payment_intent.succeeded, payment_intent.payment_failed, etc.).
Maitai supports this using a Webhook Creation capability that:
- registers a per-session webhook callback with Maitai’s hooks service and returns a unique
webhook_url(e.g.,https://hooks.trymaitai.ai/agent/<key>) - automatically infers where and how to register the webhook based on conversation context
- sends the registration request to the appropriate external service (e.g., Stripe, Shopify)
- returns WAITING_WEBHOOK until an external system POSTs an event payload to that
webhook_url
webhook_url, Maitai’s hooks service looks up the webhook key and routes the payload to the correct agent + session, then resumes execution.
See: Webhook
Add a “Webhook Creation” capability to the Payments subagent
- Open Stripe Payments Agent.
- Go to Capabilities → Add Capability → Webhook Creation.
- Invocation Mode is automatically set to Foreground (webhooks must pause execution to wait for callbacks).
- Configure authentication and optional settings:
- Authentication: Add your Stripe API key (Bearer token, API key, or Basic auth)
- Headers (optional): Additional headers needed for registration
- Timeout: How long to wait for the webhook callback (default: 10 minutes)
- Create a unique webhook URL
- Analyze the conversation context (user request, capability description, recent API calls)
- Intelligently infer the registration endpoint and payload structure (e.g., Stripe’s
/v1/webhook_endpoints) - Add your configured authentication and headers
- Make the registration HTTP call
- Wait for the external service to call back
The registration endpoint and payload structure are automatically inferred by the LLM based on context. You only need to provide authentication credentials.
- Calls
create_payment_intentAPI action → creates PaymentIntentpi_123 - Invokes webhook capability
- LLM infers from context:
- Service: Stripe
- Endpoint:
https://api.stripe.com/v1/webhook_endpoints - Payload:
{"url": "https://hooks.trymaitai.ai/agent/abc123", "enabled_events": ["payment_intent.succeeded"]}
- System adds your configured Stripe API key to the request
- Registration call succeeds
- Agent waits for Stripe to call the webhook
- Stripe calls webhook when payment succeeds
- Agent resumes and responds to user
What should call back to Maitai?
Maitai’s agent webhook endpoint (thewebhook_url on hooks.trymaitai.ai) does not verify provider signatures (like Stripe’s Stripe-Signature).
- If you need signature verification, use: Stripe → your webhook handler (verify) → Maitai
webhook_url(forward) - If you accept the risk (not recommended), you can configure Stripe to call the
webhook_urldirectly.
webhook_url the agent generated. Example:
5) Make capabilities usable (naming, auth, foreground/background, schemas)
After import, open actions and confirm the config is correct:- Invocation Mode
- Foreground: results are user-facing (used in the agent’s response)
- Background: results are stored in context only (not shown to the user)
- Response Type (API Call actions only)
- Real: call the live API
- Mock: return predefined responses (useful to prototype before auth is ready)
- Auth / Headers
- bulk import defaults auth to “none”; set the auth scheme your API needs
- Request/Response schema
- keep request schemas tight so the agent doesn’t “invent” parameters
stripe_create_payment_intent, stripe_get_customer, stripe_finalize_invoice.
6) Agent State: define the state the agent should maintain
When an API is involved, state is often the difference between a clean flow and a confusing one.- Open the agent.
- Go to the State tab.
- Add fields like:
customer_idpayment_intent_idinvoice_idlast_refund_id
- Set Read/Write scope based on which subagents should be able to see/update the field.
7) “Load the API docs” into the flow step prompts
This is the step that makes the agent behave like it “understands the docs”. Open Configuration on the parent agent and customize the relevant flow steps:Orchestrate step
Owns delegation and sequencing. Add guidance like:- Route “payment”, “charge”, “refund” → Stripe Payments Agent
- Route “customer”, “user”, “account” → Stripe Customers Agent
- Route “invoice”, “bill”, “statement” → Stripe Invoices Agent
- Required inputs per workflow (what IDs must exist before calling an endpoint)
- Happy-path sequences (e.g., lookup customer → list invoices → finalize invoice)
- Guardrails (never create resources without explicit user confirmation; if required IDs are missing, ask a clarifying question instead of guessing)
- Async lifecycles (e.g., “create PaymentIntent → wait for event → fetch final status”)
Process step
Owns result interpretation and state updates. Add guidance like:- What matters in each API response (which fields are findings worth keeping)
- What to store in state for later steps (IDs, statuses, amounts)
- How to treat API errors (what a 4xx vs 5xx means for the task)
Respond step
Owns the user-facing answer. Add guidance like:- How to summarize responses for the user (what fields matter)
- How to translate API errors into user-facing guidance
- Tone and formatting policy
8) Test in Studio (including webhook lifecycle)
- Go to Forge > Studio.
- Select the parent agent (e.g., “Stripe Agent”).
- Try prompts that force cross-domain behavior:
- “Refund the last payment for customer
cus_...” - “Create an invoice for customer
cus_...for $200 and finalize it” - “Which invoices are past due for customer
cus_...?”
- “Refund the last payment for customer
- Test an async PaymentIntent flow:
- “Create a $20 PaymentIntent for customer
cus_...and tell me when it succeeds.” - You should see the agent return WAITING_WEBHOOK plus a Webhook URL.
- When your system (or a test script) POSTs the event payload to that webhook URL, Maitai will resume the agent and continue execution.
- “Create a $20 PaymentIntent for customer
- Iterate:
- tighten subagent descriptions (better routing)
- add more “API doc” guidance to the Orchestrate/Process step prompts (better sequencing + summaries)
- narrow schemas so actions can’t be called with ambiguous inputs