Set up Metronome Token Billing through APIs

Build one working integration in the merchant's chosen environment. Use public APIs for API-addressable configuration and use the Metronome UI only for user-authenticated flows such as OAuth. Treat this skill as the orchestration layer over the current Token Billing guide and public API reference. Follow the linked schemas instead of copying generic object definitions into the integration.

Use the agent-friendly documentation index to discover current Metronome documentation when the linked pages do not cover a required operation. Prefer the direct links below for known steps, and do not invent undocumented API behavior.

For changes to an existing rate card, follow Add models to an existing rate card or Update markup on an existing rate card. Reuse the report and credential-validation guidance, and limit discovery and writes to the requested change. Before writing, capture the baseline and expected state described in Verify model additions and markup changes, then perform that verification after writing. These workflows use their own confirmation steps and concise completion message; the new-integration confirmation summary, customer-integration workflow, and setup handoff do not apply to them.

Ask for choices and confirmations

Use the agent's structured user-question tool when available and permitted for the current interaction, including plan discovery, rate-card selection, markup choices, and rate approval. Otherwise, ask in chat and wait for a reply. Bundle related onboarding choices into a compact prompt and ask conditional follow-ups only for a pricing pattern the user selected. For an existing card's markup choice, offer its stored percentage or a different percentage, with a way to enter that value.

For a new integration, the user may skip any commercial choice other than the model scope. Apply only the disclosed defaults in Discover plans and commercial terms, show them in the compact confirmation summary, and require the user to confirm the summarized business model and model selection before writing. Keep the exact object plan and price calculations in the internal report unless the user asks for them. A displayed or preselected default, an unanswered question, or elapsed time is not approval. For an existing-card addition or markup change, retain the explicit choice and approval rules in those workflows.

While waiting, continue only read-only work that does not depend on the answer, such as reading API documentation. Reuse answers and approvals already supplied for the current request, and do not ask the user to repeat information visible in a pricing page, repository, run report, or accessible remote state.

Signpost codebase research

Before announcing codebase research, confirm there is an application repository in scope: if the invocation already points at a codebase, proceed directly; if it's ambiguous, ask briefly ("Do you have an application repository I should look at, or would you like to walk through this conversationally?") rather than assuming one exists. A prospective client exploring Token Billing before writing any integration code, or a user with a billing-only sandbox, has no repository to inspect — treat that as the normal case, not an error.