Services

Services are reusable capabilities you define once and deliver to each customer — a weekly account report, a health check, a monitor that acts when something happens in your product. Each run acts as that customer, with the tools and limits you approved.

Open Services from the Workspace navigation. The page has seven tabs: Services, Access, Automations, SDK, Events, Runs, and Orders.

How services work

A service is the capability: a stable key, instructions, tools, inputs, and the ways it may be started. You edit a draft and publish it as an immutable version. Live runs always use the published version.

The catalog listing (public name, description, where it appears, who may use it) is separate from the version. Listing and access changes save live — they are not part of a draft.

A run is one execution for one user. Results are always saved to run history. Optionally deliver them by email, Slack, or webhooks.

Services do not wait on agent publish. Disable a service to block every new run without touching versions or history.

Author a few broad, parameterized services rather than many narrow ones. Put the specifics (date range, page, report request) in the inputs the caller supplies.

Create and publish

1. Open Services and choose New Service.
2. Set a Name. Aimdoc derives a stable key from the name; after the first save the key cannot change. Use this key in the Events API and SDK.
3. Write Instructions — what the background agent should do with the tools you grant. Required to publish.
4. Grant tools, add inputs if the run needs parameters, and choose invocation modes.
5. Save the draft, then Publish. Publishing freezes that version. Further edits go to a new draft until you publish again.

Status (on the Availability tab) is operational, not versioned:

• Active — eligible to run
• Disabled — blocks every new run

Use Run test / Run as contact from the editor to try the draft or the published version against a real contact. Test runs are saved to history and never delivered to the customer.

Inputs

The public input contract. Every invocation — a test, your agent, the SDK, an automation, or the API — is validated against it.

Add fields with a name, type (string, number, integer, boolean), optional description, optional allowed values (strings), and an optional default. Mark a field required when the run cannot proceed without it. Defaults apply when a value is not supplied.

Name inputs so they line up with the event properties you emit. See Events.

Output contract

Optional typed fields alongside the markdown deliverable. When you declare an output contract, every successful run must submit those fields so your app can render structured results.

Invocation modes

How this published version may be started:

• Direct — on demand from a test, your agent, the SDK, or the API
• Schedule — recurring automations on a cadence
• Event — automations and event triggers that react to product events

Turn on only the modes you intend to use.

Run budget

An optional per-run spend policy in credits. Leave both fields blank for an unbounded run. When set, the agent sees its budget at 75% of Target credits and starts wrapping up at the target; Maximum credits is the hard stop and must be greater than the target. Set both or neither. Budgets set too low reduce output quality.

Tools

Grant only what the service needs. Start from agent… copies that agent's MCP server bindings and CRM setup into the draft; the service keeps its own copy afterward.

MCP servers are connected once for your organization under Integrations → MCP Servers. On the service, pick which connected servers and tools this version may use. Credentials stay on the organization server and are resolved when the run executes.

Aimdoc data tools only see the contact the run is for:

• Contact details
• Contact conversations
• Conversation transcript
• Contact journey
• Account details
• Account activity
• Email the contact (sends through the source agent's Email channel; replies reach the agent)

You can also enable Web search & fetch, Knowledge base search, and CRM read tools (the contact's own CRM record, account, and deals — identity-verified contacts only).

When a service calls a connected MCP server with Aimdoc identity, the request includes extra assertion claims so you can tell a background run from a live chat. See Assertions from background service runs.

Listing and availability

Open the service's Listing and Availability tabs. These save live.

Catalog listing is what customers (and your agent) see:

• Public name and short description
• Longer description of what the service does, what it needs, and what they get back
• Preview listing opens the anonymous catalog view in a new tab (after you have published)

Surfaces control where the service is offered:

• Agent — your customer-facing agent can offer and run it. Optionally limit which agents.
• Aimdoc UI — the Aimdoc-hosted catalog you can embed in your app
• SDK — your own UI via the SDK catalog
• Server API — invocation from your backend with an API key

Acquisition is how a customer gets access:

• Included — available to everyone who can discover it
• Request access — visible; customers ask and you approve
• Manual — visible with your availability text; you grant access yourself
• External — visible with a link to acquire it elsewhere (your pricing page, a plan)
• Stripe checkout — buyers pay through your connected Stripe account and access is granted automatically on payment. See Pricing and payments.

Default access is what every customer gets with no rule or grant:

• Discover — listed in catalogs
• Invoke — set by the acquisition mode (included allows invoke; the others deny until you grant access)
• Automate — create schedules and event automations (also needs invoke)

Per-user and per-account overrides live on the Access tab.

Access

Open Services → Access to see who can discover, run, and automate each service.

• Pending requests — customers asking for a requestable service. Approve to grant invoke (optionally automate) or deny.
• Rules — allow or deny a specific user or account for discover, invoke, or automate. Remove a rule to return that person to the service's default.
• Grants — access you issued (approved requests, a plan you manage elsewhere). Several grants can coexist; revoking one does not remove another. A grant can carry a counted allowance: a number of included runs that reset each billing period or never. Customers see runs remaining in the catalog. Using up an allowance never revokes the grant.
• Preview as customer — see the catalog and allowed actions for a specific user, account, or anonymous visitor.
• Audit log — grants, revocations, requests, and decisions.

A service can be fully live for event triggers while appearing in no catalog — set Discover to deny and leave Event triggers on. That is the shape for internal features or a service built for one customer.

Pricing and payments

Sell a service through your own Stripe account. Buyers pay you directly. You stay the merchant of record and handle receipts, refunds, and disputes in your Stripe Dashboard; Aimdoc keeps service access in sync with what was paid for.

Connect Stripe

Open Integrations → Stripe Payments and choose Set up Stripe payments. Stripe collects your business, identity, and bank details on its own hosted pages; Aimdoc never sees them. The tab shows your account status (Onboarding incomplete, Ready to accept payments, or Action required) and lets you continue onboarding, open your Stripe Dashboard, refresh the status, or disconnect.

Disconnecting stops new checkouts and price activation immediately. Existing subscriptions and orders keep their own lifecycle, and your Stripe account is not deleted.

Price a service

Once Stripe is ready, open the service's Pricing tab. One price package applies per service:

• Billing — a one-time payment with access that lasts forever or a fixed number of days, or a subscription billed every week, month, or year. Prices are in USD.
• Included runs — leave blank for unlimited, or set how many runs the purchase includes. Choose whether runs reset each billing period or form one pack for the whole subscription, and whether a run is counted when it is started (failures Aimdoc causes are refunded) or completed successfully.
• Buyers may also schedule / automate this service — grants Automate along with Invoke.

The panel estimates what you keep from each payment after Stripe processing, the Aimdoc platform fee, and the credits the included runs consume. Save the draft, then Activate price to create it in your Stripe account. Activating a new price archives the previous one; existing orders keep the terms they were bought on.

Finally, set Acquisition to Stripe checkout on the Availability tab so catalogs offer the purchase.

What buyers see

A priced service shows its price wherever it is listed: your agent, the Aimdoc-hosted embed, your own SDK UI, and the chat widget. Purchase opens Stripe Checkout in a new tab and returns the buyer to your page. Access activates only when Stripe confirms the payment, and the catalog unlocks the service in place without a reload.

Buyers see their purchases (active, cancelling, payment due, cancelled, expired, refunded, or disputed) in the catalog's Purchases list. Manage subscription opens Stripe's billing portal on your account, where they can update their card or cancel at the end of the period.

Orders

Services → Orders lists every purchase across services, and each service has its own Orders tab. A subscription the buyer has cancelled shows as Cancelling until the period ends: access continues and nothing more is charged.

Automations

Open Services → Automations to create a scheduled or event-driven copy for one customer:

• Pick the service and the contact the run acts on behalf of.
• Schedule — once, hourly, daily, weekly, or monthly, with a timezone and a wall-clock time. Weekly needs a weekday; monthly needs a day of month (1–28).
• Event — run when a named event fires for that contact. Optional cooldown and per-day caps apply per contact.
• Bind inputs to fixed values (and, for event automations, to fields on the event). Event properties do not become inputs unless you bind them.
• Choose delivery. Results are always saved to run history. Optionally push them to:
  • a Slack channel (requires Slack connected under Integrations)
  • Webhooks subscribed to Service Run Completed
  • Email — emails the result to the contact via the agent's email channel

You can run an automation now, pause, resume, or cancel it from the table. Access is checked again at every execution — if invoke was revoked, the automation stays visible but does not run.

Verified customers can also create and manage their own automations from the catalog in your product when Automate is allowed.

Event triggers

Event triggers (on a service, or from Services → Events) are service-level rules: whenever this event fires, run this service for whoever the event names. No per-contact setup.

Use triggers for product behavior ("when a trial is expiring, run this for that user"). Use automations for standing work on one account ("watch this customer every Monday").

Access still applies per firing. An included service runs for every contact the event names; a gated service runs only for contacts who have invoke access — everyone else is a visible skipped count, with no credits spent.

See Events to emit events from your server and to subscribe a service to them.

Runs

The Runs tab lists executions with status, the contact they ran for, and the deliverable. Open a run to read the result, follow its plan as it executes (each step shows pending, in progress, done, or skipped), inspect steps, or cancel a run that is still in progress. Customers watching a run in the catalog or the widget see the same live progress and can cancel their own runs.

Every run publishes Service Run Completed, Service Run Progress, and Service Run Failed webhook events, whichever way it was started.

Credits

Runs use credits like conversations and other Aimdoc work. Open the usage card on your dashboard to see consumption for the current billing period. Unused monthly credits do not roll over; purchased top-ups never expire.

When Services is enabled but a run does not execute, check the enablement banner and that the service is Active with a published version.

In conversation

When the Agent surface is on, your agent can discover matching services for the current contact, run them, and — when Automate is allowed and the user is identity-verified — set up a recurring automation.

Connect your MCP server and Identity Verification if the service should call your product APIs as that user.

In the widget

Identity-verified visitors also get the catalog inside the chat widget itself, on your website and in App Mode. A + control at the edge of the composer lists the services available to that customer, and runnable services appear beside the conversation starters on an empty thread. From there the customer can run a service and watch it progress, schedule it (when Automate is allowed), buy a priced service, and review their purchases and past runs.

The widget only offers services to sessions that passed identity verification with a valid user_hash; anonymous visitors see none of this. The service must also be exposed on the Agent surface for that agent.

In your product

Four ways to put the same catalog in front of signed-in customers:

1. Managed embed — drop AimdocServicesEmbed from @aimdoc/sdk-react into a page. Aimdoc hosts the catalog UI.
2. In-page catalog — AimdocServiceCatalog renders in your DOM.
3. One service — AimdocServiceLauncher renders a single service's inputs and live run progress where it belongs in your product; AimdocRunProgress follows a run you started yourself.
4. Headless — useServiceCatalog, useServiceLauncher, useRunProgress, and useServiceAutomations for a fully custom UI.

Create a publishable key under Services → SDK. Your backend signs a short-lived identity assertion with the same secret used for identify. See Services catalog.

From your server, emit events, trigger a service, or grant a customer a counted allowance of runs with an API key. See API.