# How to connect Rillet to Claude

```json
{
  "title": "How to connect Rillet to Claude",
  "toolkit": "Rillet",
  "toolkit_slug": "rillet",
  "framework": "Claude Cowork",
  "framework_slug": "claude-cowork",
  "url": "https://composio.dev/toolkits/rillet/framework/claude-cowork",
  "markdown_url": "https://composio.dev/toolkits/rillet/framework/claude-cowork.md",
  "updated_at": "2026-10-29T05:34:07.996Z"
}
```

## Introduction

Claude is Anthropic's AI assistant, available on the web, in the desktop app, and on mobile. Cowork is its agent for knowledge work, and it runs on all of those surfaces too. Connected to your apps, Claude can work with your files and services to accomplish complex tasks on your behalf.
This guide walks you through the easiest and most secure way to connect your Rillet account to Claude via Composio Connect, enabling it to list overdue Rillet invoices by customer, summarize this month's Rillet revenue recognition, prepare a Rillet accounts payable aging report, and more such actions on your behalf without compromising your account security.
Setup is the same on Claude Web, Desktop, and Cowork, and you only need to do it once. The connector is tied to your account, so it's available in all three.

## Also integrate Rillet with

- [ChatGPT](https://composio.dev/toolkits/rillet/framework/chatgpt)
- [Hermes](https://composio.dev/toolkits/rillet/framework/hermes-agent)
- [Atomic Agent](https://composio.dev/toolkits/rillet/framework/atomic-agent)

## Connect Rillet to Claude Cowork

### Connecting Rillet to Claude Web, Desktop, and Cowork
Two ways to add the Composio connector. Pick whichever you prefer.
### 1. Add with one click
Click the button. Claude opens with the Composio connector filled in. Click Add, then go to step 2.
[Add to Claude](https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Composio&connectorUrl=https%3A%2F%2Fconnect.composio.dev%2Fmcp)
### Add manually
In Claude Desktop, click Customize in the left sidebar, then select Connectors and click the + icon at the top.
Click Add custom connector and paste in the Composio MCP server URL:

```bash
https://connect.composio.dev/mcp
```

## What is the Rillet MCP server, and what's possible with it?

The Rillet MCP server is an implementation of the Model Context Protocol that connects your AI agent and assistants like Claude, Cursor, etc directly to your Rillet account. It provides structured and secure access to accounting records and workflows, so your agent can create customers, vendors, invoices, and bills, record payments and journal entries, manage contracts, and complete close tasks on your behalf.
- Customer and vendor management: Have your agent create customers, vendors, customer families, products, and related metadata for organized financial operations.
- Accounts receivable and payable: Let the agent create invoices and bills, record invoice and bill payments, issue credit memos, apply credits, and remove bills or payments created in error.
- Contract and revenue workflows: Direct your agent to create draft or active contracts, amend contract terms, and cancel pending milestones when needed.
- General ledger and banking: Instruct your agent to create accounts, initialize a chart of accounts, post balanced journal entries, register bank accounts, and add or remove bank transactions.
- Close management and custom records: Have your agent complete close checklist tasks, update metadata across accounts, bills, contracts, customers, and invoices, and create custom fields and field values for reporting.

## Supported Tools

| Tool slug | Name | Description |
|---|---|---|
| `RILLET_ADD_CUSTOMER_FAMILY_MEMBERS` | Adds members to a customer family | Adds customers to a family and moves members already in it, in one call. Naming a member that already belongs gives it a new parent, so a branch can be restructured in a single request rather than through a sequence that would be invalid halfway through. |
| `RILLET_AMEND_A_CONTRACT` | Amends a contract | Applies a contract amendment when you need to add items, retire items, or change pricing/invoicing after go-live. Unlike a full PUT update, amendments model business-time changes and preserve historical billing context. Use preview-contract-amendment to dry-run the financial impact before committing. |
| `RILLET_APPLY_CREDIT_MEMO` | Reconciles credit memo applications | Full reconcile of credit memo applications. The request body represents the desired set: missing applications are removed, new applications inserted, and existing applications updated when amount or application_date differ. |
| `RILLET_APPLY_VENDOR_CREDIT` | Applies a vendor credit to bills | Allocates an existing vendor credit balance against specific open bills, reducing net amounts payable similar to a targeted vendor payment. Use after reviewing retrieve-a-vendor-credit so you apply only the remaining unapplied balance. |
| `RILLET_BULK_UPDATE_ACCOUNT_METADATA` | Updates metadata for multiple accounts | Patches metadata on up to 1,000 accounts in one atomic request. Each account may receive different values. If an account is missing or any key or value is invalid, nothing is written for any account. Per account this behaves exactly like patch-account-metadata: keys omitted for that account are left unchanged; null, empty, and whitespace-only values clear that key. |
| `RILLET_BULK_UPDATE_BILL_METADATA` | Updates metadata for multiple bills | Patches metadata on up to 1,000 bills in one atomic request. Each bill may receive different values. If a bill is missing or any key or value is invalid, nothing is written for any bill. Per bill this behaves exactly like patch-bill-metadata: keys omitted for that bill are left unchanged; null, empty, and whitespace-only values clear that key. If any bill has a pending approval request, the entire request is rejected with a 400 and nothing is written. |
| `RILLET_BULK_UPDATE_CONTRACT_METADATA` | Updates metadata for multiple contracts | Patches metadata on up to 1,000 contracts in one atomic request. Each contract may receive different values. If a contract is missing or any key or value is invalid, nothing is written for any contract. Per contract this behaves exactly like patch-contract-metadata: keys omitted for that contract are left unchanged; null, empty, and whitespace-only values clear that key. |
| `RILLET_BULK_UPDATE_CUSTOMER_METADATA` | Updates metadata for multiple customers | Patches metadata on up to 1,000 customers in one atomic request. Each customer may receive different values. If a customer is missing or any key or value is invalid, nothing is written for any customer. Per customer this behaves exactly like patch-customer-metadata: keys omitted for that customer are left unchanged; null, empty, and whitespace-only values clear that key. Metadata-only changes are recorded in the audit log but do not trigger customer.updated webhooks or customer integration syncs. |
| `RILLET_BULK_UPDATE_INVOICE_METADATA` | Updates metadata for multiple invoices | Patches metadata on up to 1,000 invoices in one atomic request. Each invoice may receive different values. If an invoice is missing or any key or value is invalid, nothing is written for any invoice. Per invoice this behaves exactly like patch-invoice-metadata: keys omitted for that invoice are left unchanged; null, empty, and whitespace-only values clear that key. |
| `RILLET_CANCEL_A_MILESTONE` | Permanently cancels a pending milestone | Permanently forfeits a pending milestone allocation on a FULL contract without redistributing it or automatically issuing a refund. A nonzero allocation creates a linked credit memo; zero allocations do not. Retrying the saved effective_date is a no-op, while a different date conflicts. Completed milestones must be reversed before cancellation. This PUT operation sends the complete documented request representation. |
| `RILLET_COMPLETE_A_CLOSE_CHECKLIST_TASK` | Completes a close checklist task | Marks the task as prepared, recorded as completed by the connected user at the current time. Requires an OAuth connection made by a named user; API keys are rejected with HTTP 403 because they do not act as a user. A task that is already completed is rejected with HTTP 409 so an earlier preparer's record is never overwritten. Returns the updated task. |
| `RILLET_CREATE_A_BANK_ACCOUNT` | Creates a bank account | Registers a treasury bank account with currency, institution identifiers, and linkage to the GL cash account used during transaction import. Accurate mapping here ensures invoice payments, bill payments, and bank feeds all post to the same cash subledger. |
| `RILLET_CREATE_A_BANK_TRANSACTION` | Creates a bank transaction | Inserts a single bank feed line such as a wire, ACH, or adjustment when automated imports miss a statement row. Specify the hosting bank account and value dates so cash reporting matches what treasury already booked externally. |
| `RILLET_CREATE_A_BILL` | Creates a bill | Accrues a new accounts-payable bill against a vendor with subsidiary context, line items, and due dates your approval workflow consumes. Attach supporting metadata now so matching payments, amortization schedules, and document uploads stay aligned with the payable. |
| `RILLET_CREATE_A_BILL_PAYMENT` | Creates a bill payment | Books a cash or scheduled disbursement that settles all or part of a bill, updating the outstanding payable and linking treasury activity. Provide funding source details consistent with your configured payment rails so downstream bank reconciliation stays accurate. IMPORTANT: Notice this operation has a redundancy between the `bill_id` path parameter and the `billId` attribute in the request body, which takes precedence and is used in internal logic. When executing this operation, both IDs must match, otherwise the request will be rejected. This is a legacy redundancy and will be removed in future versions of this operation. |
| `RILLET_CREATE_A_CHARGE` | Create a charge | Create a charge |
| `RILLET_CREATE_A_CHART_OF_ACCOUNTS` | Creates a chart of accounts | Initializes the entire chart of accounts for a bare organization in one atomic call. The organization must have no existing chart of accounts; otherwise the request fails with 409. The complete request is validated before any accounts or groups are created; validation failures return 400 without leaving a partial chart of accounts. Structural invariants match CSV import: exactly one `Accounts Receivable`, `Accounts Payable`, `Sales Tax Liability`, and `Retained Earnings`; at least one `Unbilled Revenue`, `Prepaid Expense`, and `Deferred Revenue`. The same default group scaffold as CSV import is created. Each account's optional `parent_grouping` reuses a scaffold group by name or creates a nested group under the account type root. |
| `RILLET_CREATE_A_CONTRACT` | Creates a contract | Rillet supports two contract scope types: FULL and REVENUE_RECOGNITION_ONLY. The selected scope determines how the invoices are created and what information the user needs to provide. The FULL scope is used when contract invoices are generated and sent directly from Rillet. In this case, Rillet automatically assigns the invoice numbers. The REVENUE_RECOGNITION_ONLY scope is intended for situations where contracts and invoices are issued from another system and only need to be recorded in Rillet for accounting purposes. In this workflow, users must provide the invoice numbers manually. Other fields can be populated based on the data imported from the external system. For example, if your organization issues invoices through an external billing platform but tracks financials in Rillet, you should select REVENUE_RECOGNITION_ONLY. |
| `RILLET_CREATE_A_CREDIT_MEMO` | Creates a credit memo | Opens a customer credit memo that reduces receivable exposure before you allocate it to specific invoices. Capture subsidiary, customer, line-level reasons, and tax treatment so finance can audit why the balance changed. |
| `RILLET_CREATE_A_CUSTOMER` | Creates a customer | Creates a new customer in the Accounts Receivable catalog. Required fields: name. When providing a billing or shipping address, line1, city, zip_code, and country are required. State is required for United States addresses (use a 2-letter code such as 'TN' or 'CA') and may be omitted where it does not apply. |
| `RILLET_CREATE_A_CUSTOMER_FAMILY` | Creates a customer family | Creates a family from customers that do not already belong to one. A child may report to another child, so a multi-level hierarchy is created in one call. |
| `RILLET_CREATE_A_DRAFT_CONTRACT` | Creates a draft contract | Stages a contract in the "draft" holding state instead of creating it directly as an active contract. Draft contracts appear in the Rillet UI under "Draft" for a human to approve or reject. ## Deduplication **To prevent duplicate draft contracts on retry, supply at least one `external_references` entry with a stable `(type, id)` pair.** When you POST again with any matching `(type, id)` pair, the prior draft record is replaced with the new payload. Draft contracts created without any `external_references` are not deduplicated — every POST creates a new record. ## External reference types Each reference's `type` must match a slug already defined under Rillet Settings → External References for the organization; unknown slugs return a 400. References attached at create time are preserved when the draft contract is promoted to an active contract. |
| `RILLET_CREATE_A_JOURNAL_ENTRY` | Creates a journal entry | Posts a balanced manual journal entry with explicit debit and credit lines, posting date, and subsidiary scope for GL corrections. Prefer dedicated AR or AP APIs when the business event already exists; reserve this for adjustments your automation cannot model yet. |
| `RILLET_CREATE_AN_ACCOUNT` | Creates an account | Adds an account to the chart of accounts for the organization. The account currency is inherited from the organization, its status is ACTIVE, and its default grouping and closing behavior are derived from the selected type and subtype. |
| `RILLET_CREATE_AN_INVOICE` | Creates an invoice | A matching creation approval workflow returns HTTP 202 with invoice_id, approval_request_id, and status PENDING. This is a proposal, not a created invoice. Retrieve its contents using retrieve-an-invoice-creation-proposal. For approval proposals, pass idempotency_key on the initial call and retain it across retries. The key is optional; each call without one creates a new submission, including retries. The key does not deduplicate legacy creation when approvals are disabled or the invoice belongs to a contract. A rejected proposal remains closed; a deliberate new invoice uses a new key. Rillet supports two invoice scope types: FULL and REVENUE_RECOGNITION_ONLY. The selected scope determines how the invoice is created and what information the user needs to provide. The FULL scope is used when the invoice is generated and sent directly from Rillet. |
| `RILLET_CREATE_AN_INVOICE_PAYMENT` | Creates an invoice payment | Records a manual cash receipt against an open invoice by amount, effective date, and a GL account code that maps to a funded cash account. Rillet resolves the account code to a cash account before posting, so verify chart-of-accounts mapping when automations fail validation. |
| `RILLET_CREATE_A_PRODUCT` | Creates a product | Creates a new product (good or service) that can be referenced on contracts and invoices. Choose pricing and revenue behavior consistent with how you bill customers (one-time, recurring, usage, etc.). Set type to BUNDLE to create a bundle. |
| `RILLET_CREATE_A_REIMBURSEMENT` | Create a reimbursement | Create a reimbursement |
| `RILLET_CREATE_A_REIMBURSEMENT_PAYMENT` | Creates a reimbursement payment | Records a cash payment that settles all or part of a reimbursement. |
| `RILLET_CREATE_AUTO_PAYMENT_SETUP_LINK` | Create an auto-payment setup link | Kicks off the setup of auto-payment for a customer. This will return a URL that the customer must visit to complete the setup. If the customer already has a payment method, this will return a URL to update the payment method. |
| `RILLET_CREATE_A_VENDOR` | Creates a vendor | Adds a vendor master record the accounts-payable team can select on bills, vendor credits, and payments. Capture legal name, remit-to address, default currency, and payment terms so downstream bills inherit correct due dates and banking instructions. |
| `RILLET_CREATE_A_VENDOR_CREDIT` | Creates a vendor credit | Records a new vendor credit memo amount that reduces future payables without yet touching specific bills. After creation, use apply-vendor-credit to allocate the balance across one or more open bills. |
| `RILLET_CREATE_EXTERNAL_REFERENCE_TYPE` | Creates an external reference type | Creates a `type` for use in `external_references`. If the organization already has a type with this `slug`, it is returned unchanged with `200`; otherwise it is created and returned with `201`. Reserved names are rejected. |
| `RILLET_CREATE_FIELD` | Creates a field | Defines a new custom field (text, number, pick list, etc.) that can be attached to supported Rillet entities for reporting and automation. After creation, use create-field-value to seed allowed pick-list entries or default values teams should see in the UI. |
| `RILLET_CREATE_FIELD_VALUE` | Creates a field value | Adds a selectable value to a pick-list style custom field so users and APIs can tag entities with consistent taxonomy. Values inherit the field’s scope, so create them after the parent field exists and before importing records that reference the new code. |
| `RILLET_DELETE_A_BANK_ACCOUNT` | Deletes a bank account | Removes a bank account definition when the entity closed the account or you mistakenly created a duplicate connector mapping. Ensure no scheduled payments or open reconciliation batches still target this bank account before deletion. |
| `RILLET_DELETE_A_BANK_TRANSACTION` | Deletes a bank transaction | Removes a bank transaction row that was imported twice or created in error before it affects reconciled cash balances. Confirm treasury agrees the underlying bank activity will not return on the next feed pull before deleting. |
| `RILLET_DELETE_A_BILL` | Deletes a bill | Removes a bill that should no longer drive AP balances, typically while it remains in draft or was created in error. Verify no posted payments, accrual journals, or vendor credit applications still reference the bill before deleting. |
| `RILLET_DELETE_A_BILL_PAYMENT` | Deletes a bill payment | Reverses a previously recorded bill payment when the disbursement failed or was duplicated, restoring the bill balance accordingly. Treat this as a corrective action with the same controls you apply to voiding treasury transactions in your close process. |
| `RILLET_DELETE_A_CHARGE` | Deletes a charge | Drops a charge that should not influence spend reporting, for example duplicate imports from a card processor feed. Ensure finance agrees the underlying bank activity will not be re-imported before removing the charge permanently. |
| `RILLET_DELETE_A_CONTRACT` | Deletes a contract | Permanently removes a contract when your business rules allow deletion. Confirm downstream invoices, revenue schedules, and integrations no longer depend on this contract before deleting it. |
| `RILLET_DELETE_A_CONTRACT_DOCUMENT` | Deletes a document from a contract | Removes one attachment from a contract. The stored file is deleted unless another contract or a milestone still uses it, or the file belongs to another part of Rillet. Works for files uploaded through the API or the Rillet application, or imported from Salesforce. |
| `RILLET_DELETE_A_CREDIT_MEMO` | Deletes a credit memo | Removes a credit memo that should no longer affect AR balances, typically while it is still draft or unused. Confirm no invoice applications or downstream revenue adjustments depend on this memo before calling delete. |
| `RILLET_DELETE_A_CUSTOMER` | Deletes a customer | Permanently deletes a customer. Verify no active contracts or open invoices reference this customer first. |
| `RILLET_DELETE_A_CUSTOMER_FAMILY` | Dissolves a customer family | Dissolves the grouping. Every member becomes a standalone customer; no customer is deleted. |
| `RILLET_DELETE_A_DRAFT_CONTRACT` | Deletes a draft contract | Permanently removes a draft contract along with its line items and external references. Use this to programmatically reject a draft contract instead of doing it from the Rillet UI. |
| `RILLET_DELETE_A_DRAFT_CONTRACT_DOCUMENT` | Deletes a document from a draft contract | Removes one attachment from a draft contract. The stored file is deleted unless a contract, another draft contract or a milestone still uses it, or the file belongs to another part of Rillet. Works for files uploaded through the API or the Rillet application, or imported from Salesforce. A file imported from Salesforce stays removed when the draft contract is imported again, unless a newer version of it is uploaded in Salesforce. |
| `RILLET_DELETE_A_JOURNAL_ENTRY` | Deletes a journal entry | Deletes a manual journal entry that should be excluded from the ledger, typically prior to period lock while corrections remain allowed. Verify dependent reconciliations or downstream consolidations no longer rely on the entry before removal. |
| `RILLET_DELETE_AN_INVOICE` | Deletes an invoice | Permanently removes an invoice when your policy allows it (for example draft or voided states). Confirm no downstream payments or revenue postings still depend on this invoice. |
| `RILLET_DELETE_AN_INVOICE_DOCUMENT` | Deletes a document from an invoice | Removes one attachment from an invoice and deletes the stored file. Works for files uploaded through the API or the Rillet application. Removing a file from an invoice that was already sent does not change the email that went out. |
| `RILLET_DELETE_AN_INVOICE_PAYMENT` | Deletes an invoice payment | Reverses a previously recorded uncleared invoice payment, restoring the invoice balance accordingly. Only uncleared payments can be deleted; cleared or reconciled payments are rejected. Treat this as a corrective action with the same controls you apply to voiding treasury transactions in your close process. |
| `RILLET_DELETE_A_PRODUCT` | Deletes a product | Permanently removes a product or bundle. Ensure no in-flight contracts or invoices require this product before deleting. |
| `RILLET_DELETE_A_REIMBURSEMENT` | Deletes a reimbursement | Removes a reimbursement that was created prematurely or duplicated during intake so it no longer blocks payroll totals. Confirm no outbound payments or GL accruals were posted against the reimbursement before deleting it. |
| `RILLET_DELETE_A_REIMBURSEMENT_PAYMENT` | Deletes a reimbursement payment | Reverses an uncleared reimbursement payment that was recorded in error. |
| `RILLET_DELETE_A_USAGE_RECORD` | Deletes a usage record | Removes the usage entry for a single contract item on a specific calendar date. This is narrower than upsert-a-usage-record and is ideal when you need to wipe a mistaken day without resending the entire usage payload. |
| `RILLET_DELETE_A_VENDOR` | Deletes a vendor | Removes a vendor you no longer expect to pay. Confirm no open bills, credits, or scheduled payments still reference this vendor to avoid orphaned payables. |
| `RILLET_DELETE_A_VENDOR_CREDIT` | Deletes a vendor credit | Permanently removes a vendor credit that should not remain in the subledger. Ensure no applications or downstream reconciliations still rely on this credit before deleting. |
| `RILLET_DELETE_CREDIT_MEMO_APPLICATIONS` | Unapplies all credit memo applications | Removes every application from this credit memo, reverting all invoice allocations. |
| `RILLET_DELETE_FIELD_VALUE` | Deletes a field value | Retires a pick-list option that should no longer be selectable while keeping older records intact for read-only history. Confirm no automation or validation rules still require the value before removal to avoid breaking bulk imports. |
| `RILLET_END_AN_OPEN_ENDED_CONTRACT` | Ends an open-ended contract | Sets an explicit end date on a contract that previously had no close date (open-ended). Provide the final end_date in the request body; downstream invoicing and revenue recognition honor the new boundary. This PUT operation sends the complete documented request representation. |
| `RILLET_GET_API_KEY_INFORMATION` | Gets API key information | Confirms the caller’s API key is recognized and returns basic identity metadata such as organization context when authentication succeeds. Integrations should call this during bootstrap or rotation to distinguish invalid keys from broader connectivity failures. |
| `RILLET_GET_CURRENT_ORGANIZATION` | Get Current Organization | Return the organization associated with the connected Rillet credentials, including its ID, currency, timezone, and trade name. |
| `RILLET_GET_FINANCIAL_REPORT` | Get Financial Report | Return either a trial balance for a date range or a balance sheet as of a date, with optional subsidiary and book filters. This reads calculated accounting results and does not post or modify entries. |
| `RILLET_GET_PAYMENT_METHOD` | Gets payment method | Returns the payment method configured for auto-payment for the given customer. |
| `RILLET_HEALTH` | Returns service health | Lightweight liveness probe that returns HTTP 200 when the service process is running, without exercising downstream databases or queues. Use for load balancer health checks where you only need to know the JVM responded. |
| `RILLET_LIST_ACCOUNTING_REFERENCE_DATA` | List Accounting Reference Data | Return one complete Rillet reference collection selected by resource: chart accounts, subsidiaries, books, bank accounts, tax rates, or custom fields. Use it to resolve IDs and accounting configuration before querying transactions or reports. |
| `RILLET_LIST_ALL_APPROVAL_WORKFLOWS` | Lists all approval workflows | Returns every approval workflow in the organization tied to the API credentials, active and inactive, grouped by the kind of record they apply to and ordered by ascending `priority` within each group. This endpoint is not paginated and returns the complete set. |
| `RILLET_LIST_ALL_CHARGES` | Lists all charges | Pages card or out-of-pocket employee charges awaiting policy review, subsidiary allocation, or conversion into reimbursable payables. Filter by subsidiary_id or updated.gt when syncing corporate card feeds into downstream expense automation. |
| `RILLET_LIST_ALL_CONTRACT_ITEM_USAGE_RECORDS` | Lists all contract item usage records | Returns historical usage quantities for a contract item, newest first, with optional pagination cursors. Use before upsert-a-usage-record or delete-a-usage-record to understand existing coverage for each date. |
| `RILLET_LIST_ALL_CREDIT_MEMOS` | Lists all credit memos | Returns customer credit memos with pagination and filters for application state, customer, and subsidiaries. Use credit memo ids with retrieve-a-credit-memo before updates or when applying credits to invoices. |
| `RILLET_LIST_ALL_CUSTOMER_FAMILIES` | Lists all customer families | Returns customer families with pagination and optional search or update filters. The response does not include members; use list-customer-family-members to read them. |
| `RILLET_LIST_ALL_DRAFT_CONTRACTS` | Lists all draft contracts | Returns draft contracts with cursor pagination. Draft contracts are staged records that appear in the Rillet UI under "Draft" for a human to approve or reject before they become active contracts. |
| `RILLET_LIST_ALL_INVOICE_PAYMENTS` | Lists payments for a given invoice | Returns every payment attempt tied to a single invoice, including successful, uncleared, and failed rows with their public status. Pair with retrieve-an-invoice when reconciling an account statement against what Rillet already applied. |
| `RILLET_LIST_ALL_INVOICES_PAYMENTS` | Lists all invoice payments | Pages every customer payment recorded against invoices across the organization, independent of which invoice it settled. Use updated.gt and sort_by when syncing integrations; follow the pagination cursor until no next page remains. |
| `RILLET_LIST_ALL_METADATA_DEFINITIONS` | Lists all metadata definitions | Returns the organization's metadata definitions: the custom fields that can hold values on contracts, customers, and invoices. Keys are permanent identifiers derived from the name at creation; API consumers bind to keys, which never change on rename. At most 50 active definitions can be assigned to one entity type. Definitions are managed in Settings, not through this API. |
| `RILLET_LIST_ALL_PRODUCTS` | Lists all products | Returns sellable products and services for accounts receivable (contracts, invoices). Supports pagination and optional filters such as status, currency and type. |
| `RILLET_LIST_ALL_REIMBURSEMENTS` | Lists all reimbursements | Surfaces reimbursement requests created from approved charges or manual submissions, including subsidiary and freshness filters for payroll sync. Use pagination cursors for large populations and pair with retrieve-a-reimbursement when a row needs detailed audit context. |
| `RILLET_LIST_ALL_VENDOR_CREDITS` | Lists all vendor credits | Returns vendor credits with pagination and filters for vendor, subsidiary, and freshness. Credits represent vendor-issued balance reductions you can later apply to bills using apply-vendor-credit. |
| `RILLET_LIST_BANK_TRANSACTIONS` | List Bank Transactions | Return one page of bank transactions, optionally filtered by bank account, subsidiary, transaction-date range, or update time. |
| `RILLET_LIST_BILL_PAYMENTS` | Lists bill payments | Enumerates disbursements recorded against a specific bill, useful when reconciling vendor statements to internal cash movements. Combine with retrieve-a-bill to understand remaining balance after each payment posts. |
| `RILLET_LIST_BILLS` | List Bills | Return one page of bills, optionally filtered by subsidiary, vendor, payment status, or update time. |
| `RILLET_LIST_CLOSE_CHECKLIST_TASKS` | Lists close checklist tasks | Returns the month-end close checklist for one accounting month: every task with its notes, due date, preparer, reviewer queue, completion and sign-off state. Use it to report close progress or to find the task_id needed by update, complete and sign-off. Resolve preparer and reviewer user ids to people with list-members (match on user_id). Responds with HTTP 404 when no checklist exists for the month. |
| `RILLET_LIST_CONTRACT_DOCUMENTS` | Lists documents attached to a contract | Returns all attached documents, including those uploaded through the Rillet application or imported from Salesforce. Each download URL is valid for up to 1 hour; call this endpoint again to obtain fresh URLs. Documents are listed oldest first. Returns an empty `documents` array when the contract has no attachments. |
| `RILLET_LIST_CONTRACTS` | List Contracts | Return one page of contracts, optionally filtered by subsidiary, customer, lifecycle status, or inclusive/exclusive start and end date ranges. |
| `RILLET_LIST_CUSTOMER_FAMILY_MEMBERS` | Lists the members of a customer family | Returns the members of a customer family with pagination. Each member names the member it reports to, so you can rebuild the tree. Newest first, not alphabetical. |
| `RILLET_LIST_CUSTOMERS` | List Customers | Return one page of accounts-receivable customers, optionally filtered by name, external reference, or update time. |
| `RILLET_LIST_DRAFT_CONTRACT_DOCUMENTS` | Lists documents attached to a draft contract | Returns all attached documents, including those uploaded through the Rillet application or imported from Salesforce. Each download URL is valid for up to 1 hour; call this endpoint again to obtain fresh URLs. Documents are listed oldest first. Returns an empty `documents` array when the draft contract has no attachments. Once the draft contract is confirmed, its documents are listed on the contract instead. |
| `RILLET_LIST_INVOICE_DOCUMENTS` | Lists documents attached to an invoice | Returns all attached documents, including those uploaded through the Rillet application. Each download URL is valid for up to 1 hour; call this endpoint again to obtain fresh URLs. Documents are listed oldest first. Returns an empty `documents` array when the invoice has no attachments. |
| `RILLET_LIST_INVOICES` | List Invoices | Return one page of invoices, optionally filtered by subsidiary, customer, payment status, overdue state, external reference, or update time. Results intentionally omit bank-account and full postal-address details. |
| `RILLET_LIST_JOURNAL_ENTRIES` | List Journal Entries | Return one page of journal entries, optionally filtered by subsidiary, book, posting-date range, account IDs, or update time. Each result includes debit and credit lines with exact decimal amount strings. |
| `RILLET_LIST_JOURNAL_ENTRY_DOCUMENTS` | Lists documents attached to a manual journal entry | Returns all attached documents, including those uploaded through the Rillet application. Each download URL is valid for up to 1 hour; call this endpoint again to obtain fresh URLs. Returns an empty array when the entry has no attachments. System-generated and non-posting entries are not supported. |
| `RILLET_LIST_MEMBERS` | Lists organization members | Returns the identity of each member of the organization tied to the API credentials. This endpoint carries identity only (id, user, email, name, status); it does not return role assignments. Use list-role-assignments to discover which member is assigned which role, and list-roles to resolve what each role authorizes. |
| `RILLET_LIST_REIMBURSEMENT_PAYMENTS` | Lists reimbursement payments | Lists payments recorded against a reimbursement so external systems can reconcile its paid balance. |
| `RILLET_LIST_REPORTS_JOURNAL_ENTRIES` | Lists journal entries with reporting currency amounts | Returns journal entries with line item amounts converted to the reporting currency. |
| `RILLET_LIST_ROLE_ASSIGNMENTS` | Lists role assignments | Returns which organization member is assigned which role and the scope of that assignment. References roles and members by id only; join against list-roles and list-members to resolve names. This endpoint is not the source of truth for role or subsidiary names. |
| `RILLET_LIST_ROLES` | Lists roles | Returns every role defined in the organization along with the flat set of permission keys it grants. Each permission is an opaque, colon-delimited string; treat it as an opaque identifier and do not rely on its internal structure. |
| `RILLET_LIST_VENDORS` | List Vendors | Return one page of accounts-payable vendors, optionally limited to records updated after a timestamp. Results omit tax IDs, addresses, email addresses, payment terms, custom fields, and account-code details. |
| `RILLET_MATCH_BANK_TRANSACTIONS_AS_TRANSFER` | Matches two bank transactions as a transfer | Matches two bank transactions as a transfer. The source transaction may be incoming or outgoing; the transaction amounts determine the direction. Cross-subsidiary transfers require access to both subsidiaries. For a same-subsidiary transfer with a difference, provide reconciliation_adjustment.account_id; reconciliation_adjustment.fields apply to the adjustment line. If either bank transaction has a fee, provide fees_account_id to book it. A transfer with fees on both bank transactions is not supported. |
| `RILLET_MATCH_BANK_TRANSACTIONS_TO_RECORDS` | Matches bank transactions to existing records | Matches bank transactions to existing records. You can include different record types in one request, subject to the supported match combinations. To book a difference, provide reconciliation_adjustment.account_id. Optional reconciliation_adjustment.fields are custom field and value IDs applied to the adjustment entry, not to the matched records. Rillet calculates the difference. |
| `RILLET_MATCH_BANK_TRANSACTIONS_WITH_QUICK_ENTRY` | Matches bank transactions with new quick entries | Creates a separate quick entry for each bank transaction in transaction_ids, using the same requested details. The transactions are not combined into one many-to-one (N:1) match. With line_items, supply exactly one ID. |
| `RILLET_PATCH_ACCOUNT_METADATA` | Patches account metadata | Partial update. Keys omitted from the request body are left unchanged; send a key with a null, empty, or whitespace-only value to clear it. Prefer this over update-account-metadata when setting or clearing individual keys, as it cannot disturb keys you did not name. Archived keys may only be cleared, never changed. Every key must name a definition assigned to accounts: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. |
| `RILLET_PATCH_BILL_METADATA` | Patches bill metadata | Partial update. Keys omitted from the request body are left unchanged; send a key with a null, empty, or whitespace-only value to clear it. Prefer this over update-bill-metadata when setting or clearing individual keys, as it cannot disturb keys you did not name. Archived keys may only be cleared, never changed. Every key must name a definition assigned to bills: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. Writes are rejected with a 400 while the bill has a pending approval request. |
| `RILLET_PATCH_CONTRACT_METADATA` | Patches contract metadata | Partial update. Keys omitted from the request body are left unchanged; send a key with a null, empty, or whitespace-only value to clear it. Prefer this over update-contract-metadata when setting or clearing individual keys, as it cannot disturb keys you did not name. Archived keys may only be cleared, never changed. Every key must name a definition assigned to contracts: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. |
| `RILLET_PATCH_CUSTOMER_METADATA` | Patches customer metadata | Partial update. Keys omitted from the request body are left unchanged; send a key with a null, empty, or whitespace-only value to clear it. Prefer this over update-customer-metadata when setting or clearing individual keys, as it cannot disturb keys you did not name. Archived keys may only be cleared, never changed. Every key must name a definition assigned to customers: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. |
| `RILLET_PATCH_INVOICE_METADATA` | Patches invoice metadata | Partial update. Keys omitted from the request body are left unchanged; send a key with a null, empty, or whitespace-only value to clear it. Prefer this over update-invoice-metadata when setting or clearing individual keys, as it cannot disturb keys you did not name. Archived keys may only be cleared, never changed. Every key must name a definition assigned to invoices: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. |
| `RILLET_PREVIEW_CONTRACT_AMENDMENT` | Previews contract amendment | Preview a contract that has been amended. This has no effect on the actual contract, only provides a preview of what a contract will look like after it is amended. |
| `RILLET_PREVIEW_INVOICE_SCHEDULE` | Preview the invoice schedule for a contract | Computes and returns the invoice schedule the given contract would produce, without creating the contract or persisting anything. |
| `RILLET_REFRESH_A_BUNDLE` | Refreshes a bundle | Updates the details the bundle keeps for each component product to the products' current values. Contracts that already sold the bundle don't change. |
| `RILLET_REMOVE_A_CUSTOMER_FAMILY_MEMBER` | Removes a member from a customer family | Removes one customer from the family; the customer itself is untouched. Anyone reporting to it moves up to its own parent. If this would leave the family with a single member it is dissolved instead. The root parent cannot be removed this way: dissolve the family instead. |
| `RILLET_RENAME_A_CUSTOMER_FAMILY` | Renames a customer family | Changes the family's name. Membership is untouched: anything else in the body is ignored, so use the members endpoints to change who belongs. |
| `RILLET_RETRIEVE_A_BANK_ACCOUNT` | Retrieves a bank account | Returns configuration and status for a single bank account, including identifiers downstream connectors need when refreshing balances. Use before deleting or updating metadata so you preserve institution codes and default subsidiary routing. |
| `RILLET_RETRIEVE_A_BANK_ACCOUNT_BALANCE` | Retrieves a bank account balance | Returns the latest stored bank balance on or before the requested date in the bank account's native currency. The response includes the stored balance date so consumers can identify when the latest available balance predates the requested date. |
| `RILLET_RETRIEVE_A_BANK_TRANSACTION` | Retrieves a bank transaction | Fetches one bank transaction with counterparty text, amounts, and links to the Rillet transactions it settled. Use the reconciled transaction IDs to retrieve the reconciled bills, invoices, journal entries, or other source records. |
| `RILLET_RETRIEVE_A_BILL` | Retrieves a bill | Returns the authoritative bill record including vendor linkage, approval state, open balance, and document references. Fetch before update-a-bill because PUT semantics require you to resubmit every field to avoid nulling omitted values. |
| `RILLET_RETRIEVE_ACCOUNT_METADATA` | Retrieves account metadata | Returns this account's metadata values keyed by definition key. Keys with no value are omitted. Existing values held by archived definitions remain readable here. Definition names, types and status come from list-all-metadata-definitions. |
| `RILLET_RETRIEVE_A_CHARGE` | Retrieves a charge | Fetches a single charge with merchant metadata, amounts, and workflow state so reviewers can decide coding before reimbursement. Use this after list-all-charges surfaces an id that needs manual inspection or attachment to a bill. |
| `RILLET_RETRIEVE_A_CONTRACT` | Retrieves a contract | Returns the expanded contract including items, schedules, and metadata required before updates or amendments. Always retrieve before issuing a full PUT update so you preserve fields you do not intend to clear. |
| `RILLET_RETRIEVE_A_CREDIT_MEMO` | Retrieves a credit memo | Loads the full credit memo payload, including remaining balance, applications, and tax metadata you must echo on PUT updates. Always retrieve before editing because update-a-credit-memo replaces the entire resource when fields are omitted. |
| `RILLET_RETRIEVE_A_CUSTOMER` | Retrieves a customer | Returns a single customer record including billing profile details, which are needed for updates. |
| `RILLET_RETRIEVE_A_CUSTOMER_FAMILY` | Retrieves a customer family | Returns a single customer family with its name, root parent and member count. The response does not include members; use list-customer-family-members to read them. |
| `RILLET_RETRIEVE_A_DRAFT_CONTRACT` | Retrieves a draft contract | Returns a draft contract by id, including its line items and any attached external references. |
| `RILLET_RETRIEVE_A_JOURNAL_ENTRY` | Retrieves a journal entry | Retrieves a journal entry with every line, account reference, and reconciliation flag needed for close review or downstream edits. Call before update-a-journal-entry so you can merge new edits with existing lines without accidentally dropping balances. |
| `RILLET_RETRIEVE_AN_APPROVAL_WORKFLOW` | Retrieves an approval workflow | Returns one approval workflow: the conditions that decide which entries it applies to, and the ordered layers of approvers that must sign off. This is the control definition, not a record of approvals given. Approval workflows are not versioned — the response describes the workflow as it stands now, and an update overwrites it in place. |
| `RILLET_RETRIEVE_AN_INVOICE` | Retrieves an invoice | Returns invoice details including line items, tax breakdown, and linkage to contracts or customers. Use Accept application/json for structured data; application/pdf is only for human-readable exports when enabled. |
| `RILLET_RETRIEVE_AN_INVOICE_CREATION_PROPOSAL` | Retrieves a pending invoice creation proposal | Retrieve the captured contents of an invoice awaiting creation approval. No effective invoice exists yet. After approval, retrieve the invoice through the normal invoice endpoint. Pending proposals are excluded from invoice lists. |
| `RILLET_RETRIEVE_A_PRODUCT` | Retrieves a product | Returns a single product or bundle definition, including pricing configuration used on contracts and invoices. |
| `RILLET_RETRIEVE_A_REIMBURSEMENT` | Retrieves a reimbursement | Returns the full reimbursement packet with employee linkage, funding instructions, and approval history for a single id. Helpful when validating totals before releasing ACH batches or answering employee support tickets. |
| `RILLET_RETRIEVE_A_SUBSIDIARY` | Retrieves a subsidiary | Returns one subsidiary by id for the authenticated organization. Call list-all-subsidiaries first if you need to resolve which subsidiary id to use. |
| `RILLET_RETRIEVE_A_VENDOR` | Retrieves a vendor | Fetches the full vendor profile including identifiers you must echo back on PUT updates. Use before editing to avoid wiping optional fields, and when validating tax or payment metadata during bill entry. |
| `RILLET_RETRIEVE_A_VENDOR_CREDIT` | Retrieves a vendor credit | Loads a single vendor credit including remaining balance and application history. Retrieve before updating or applying so you know how much capacity is left to allocate to bills. |
| `RILLET_RETRIEVE_BILL_METADATA` | Retrieves bill metadata | Returns this bill's metadata values keyed by definition key. Keys with no value are omitted. Existing values held by archived definitions remain readable here. Definition names, types and status come from list-all-metadata-definitions. |
| `RILLET_RETRIEVE_CASH_FLOW_STATEMENT_REPORT` | Retrieves cash flow statement report | Returns a cash flow statement report for the specified date range. |
| `RILLET_RETRIEVE_CONTRACT_METADATA` | Retrieves contract metadata | Returns this contract's metadata values keyed by definition key. Keys with no value are omitted, including values held by archived definitions, which stay readable here. Definition names, types and status come from list-all-metadata-definitions. |
| `RILLET_RETRIEVE_CUSTOMER_METADATA` | Retrieves customer metadata | Returns this customer's metadata values keyed by definition key. Keys with no value are omitted, including values held by archived definitions, which stay readable here. Definition names, types and status come from list-all-metadata-definitions. |
| `RILLET_RETRIEVE_EXECUTIVE_PL_REPORT` | Retrieves executive P&L report | Returns an executive profit and loss report with margins for the specified date range. |
| `RILLET_RETRIEVE_INCOME_STATEMENT_REPORT` | Retrieves income statement report | Returns an income statement (profit and loss) report for the specified date range. |
| `RILLET_RETRIEVE_INVOICE_METADATA` | Retrieves invoice metadata | Returns this invoice's metadata values keyed by definition key. Keys with no value are omitted, including values held by archived definitions, which stay readable here. Definition names, types and status come from list-all-metadata-definitions. |
| `RILLET_RETRIEVE_LAST_BOOK_CLOSED_PERIOD` | Retrieves last book closed period | Returns the most recently closed accounting period for book-close workflows, including closed-on timestamps your automation can cache. When no period has ever been closed the API responds with HTTP 404, so treat a missing resource as "not yet closed" rather than an outage. |
| `RILLET_RETRIEVE_WATERFALL_REPORT` | Retrieves ARR waterfall report | Returns the ARR waterfall dataset for the requested month with optional breakdown dimensions, subsidiary filters, and pagination cursors for large tenants. Finance teams use this to explain beginning ARR, new business, expansion, contraction, and churn between periods. |
| `RILLET_REVERSE_A_MILESTONE_COMPLETION` | Reverses a milestone completion | Removes the current completion and its recognition effect without cancelling the milestone, issuing a credit, or changing its allocation. The milestone must currently be completed. The milestone change and required revenue journal regeneration commit atomically. |
| `RILLET_SIGN_OFF_A_CLOSE_CHECKLIST_TASK` | Signs off a close checklist task as reviewer | Records the connected user's review sign-off on a completed task. Requires an OAuth connection made by a named user; API keys are rejected with HTTP 403. The task must be completed first (HTTP 409 otherwise). Only a reviewer on the task who has not signed off yet may sign off (HTTP 403 otherwise); when the organization enforces an ordered reviewer queue, it must also be their turn. A fully signed-off task is rejected with HTTP 409. Returns the updated task. |
| `RILLET_SUBMIT_AGENT_FEEDBACK` | Reports API or MCP bugs and missing features | Found something surprising, confusing, or missing while using the API or MCP tools? Tell us, even if you found a workaround. Report unclear tool schemas, confusing results, missing filters, excessive pagination, or missing bulk operations. Send one observation per request. Describe what you were trying to do and what you expected; for bugs, also include what actually happened. For MCP feedback, set endpoint to /mcp and include the affected tool name in description, for example list_all_journal_entries. You do not need to know the tool's underlying REST path. For API feedback, set endpoint to the affected API path. A writable API key or OAuth token with write scope is required. The organization and submitting credential are recorded from authentication, so you do not need to provide them. |
| `RILLET_UPDATE_A_BANK_TRANSACTION` | Updates a bank transaction | Adjusts memo, categorization, or reconciliation metadata on an existing bank transaction without re-importing the entire feed batch. Supply the full body expected by the schema so optional fields you intend to keep are not unintentionally cleared. This PUT operation sends the complete documented request representation. |
| `RILLET_UPDATE_A_BILL` | Updates a bill | IMPORTANT: This is a full-replace operation (PUT semantics). All fields must be included in the request body — omitting any field will set it to null, wiping existing data. Always call retrieve-a-bill first to fetch the current record, then include ALL existing fields in your update request along with your changes. Bills with line allocations return 422 BillHasSubsidiaryAllocations, even for a no-op update. These allocations cannot be sent through this API; edit the bill in Rillet instead. |
| `RILLET_UPDATE_ACCOUNT_METADATA` | Updates account metadata | IMPORTANT: This is a full-replace operation (PUT semantics). Every active metadata key omitted from the request body is cleared. To set or clear individual keys without disturbing the rest, use patch-account-metadata instead. Null, empty, and whitespace-only values clear a single key. Archived keys may only be cleared, never changed. Every key must name a definition assigned to accounts: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. |
| `RILLET_UPDATE_A_CLOSE_CHECKLIST_TASK` | Updates a close checklist task | Partial update of one task's details and assignments. Fields omitted from the body are left unchanged. Completion and reviewer sign-offs cannot be set or cleared here; use complete-a-close-checklist-task and sign-off-a-close-checklist-task. A reviewer who has already signed off keeps their place in the queue: a reviewer_ids list that drops or moves them is rejected with HTTP 409. Every preparer and reviewer must be an active member of the organization (see list-members). Returns the updated task. |
| `RILLET_UPDATE_A_CREDIT_MEMO` | Updates a credit memo | IMPORTANT: This is a full-replace operation (PUT semantics). All fields must be included in the request body — omitting any field will set it to null, wiping existing data. Always call retrieve-a-credit-memo first to fetch the current record, then include ALL existing fields in your update request along with your changes. |
| `RILLET_UPDATE_A_CUSTOMER` | Updates a customer | Updates a single customer record in the catalog. IMPORTANT: This is a full-replace operation (PUT semantics). All fields must be included in the request body — omitting any field will set it to null, wiping existing data. Always call retrieve-a-customer first to fetch the current record, then include ALL existing fields in your update request along with your changes. Exceptions that keep stored data when the field is omitted: - metadata: omit it to keep all existing metadata, or send only the keys you want to set or clear. - addresses: omit address and billing_addresses to keep the stored billing addresses, and likewise shipping_address and shipping_addresses. This is for backward compatibility: integrations built before customers could have several addresses won't wipe the ones they don't send. |
| `RILLET_UPDATE_A_DRAFT_CONTRACT` | Updates a draft contract | Replaces the draft contract identified by `draft_contract_id` with the supplied payload. The body shape matches `POST /draft-contracts` — items and external_references on the existing record are fully replaced. Returns 404 if the id is not a draft contract in the organization. Exceptions that keep stored data when the field is omitted: - shipping_customer_id, billing_address_id, shipping_address_id: omit them to keep the draft's current ship-to customer and addresses, or send null to clear them. - email_selection: omit it to keep the draft's current recipients. This is for backward compatibility: integrations built before these fields existed won't clear them on every update. |
| `RILLET_UPDATE_A_JOURNAL_ENTRY` | Updates a journal entry | Replaces the lines and header metadata on an existing manual journal entry, subject to the same balancing rules as creation. Always include the complete line list retrieved beforehand because partial payloads can clear fields the API treats as optional. |
| `RILLET_UPDATE_A_MILESTONE_COMPLETION` | Records or corrects a milestone completion | Creates or fully replaces the current completion on a milestone in a FULL contract. The reference may be the milestone UUID or its case-insensitive key. The completion date must fall within the owning line term. Omitted or null memo and external_references values clear those fields. An identical request is a no-op. The milestone change and required revenue journal regeneration commit atomically. |
| `RILLET_UPDATE_AN_APPROVAL_WORKFLOW` | Updates an approval workflow | Replaces an approval workflow's definition. The whole definition is required — a partial body is rejected, not merged, and fields this contract does not define are ignored. Send `type` and `active` back as read; changing either here is rejected, and combinations the Rillet app cannot configure are rejected too (see the individual fields). Entries already awaiting approval are unaffected, because an entry copies the layers it needs when approval starts; only entries registered after this call use the new definition. Deadlines and layer escalation rules are not part of this contract and are cleared, exactly as saving a workflow in Rillet clears them. |
| `RILLET_UPDATE_AN_INVOICE` | Updates an invoice | IMPORTANT: This is a full-replace operation (PUT semantics). All fields must be included in the request body — omitting any field will set it to null, wiping existing data. Always call retrieve-an-invoice first to fetch the current record, then include ALL existing fields in your update request along with your changes. Exceptions that keep stored data when the field is omitted: - metadata: omit it to keep all existing metadata, or send only the keys you want to set or clear. - shipping_customer_id, billing_address_id, shipping_address_id: omit them to keep the invoice's current ship-to customer and addresses, or send null to clear them. This is for backward compatibility: integrations built before these fields existed won't clear them on every update. - email_selection: omit it to keep the invoice's current recipients. |
| `RILLET_UPDATE_AN_INVOICE_PAYMENT` | Updates an invoice payment | Replaces the amount, date, and cash account on an existing uncleared invoice payment. Only uncleared payments can be updated; cleared or reconciled payments are rejected. This is a full-replace operation (PUT semantics) — include all fields in the request body. |
| `RILLET_UPDATE_A_PRODUCT` | Updates a product | Updates a single product or bundle definition in the catalog. IMPORTANT: This is a full-replace operation (PUT semantics). Include every field expected by ProductRequest; omitted fields may be cleared. Call retrieve-a-product first, merge your changes, then submit the full body. |
| `RILLET_UPDATE_A_VENDOR` | Updates a vendor | IMPORTANT: This is a full-replace operation (PUT semantics). All fields must be included in the request body — omitting any field will set it to null, wiping existing data. Always call retrieve-a-vendor first to fetch the current record, then include ALL existing fields in your update request along with your changes. |
| `RILLET_UPDATE_A_VENDOR_CREDIT` | Updates a vendor credit | IMPORTANT: This is a full-replace operation (PUT semantics). All fields must be included in the request body — omitting any field will set it to null, wiping existing data. Always call retrieve-a-vendor-credit first to fetch the current record, then include ALL existing fields in your update request along with your changes. |
| `RILLET_UPDATE_BILL_METADATA` | Updates bill metadata | IMPORTANT: This is a full-replace operation (PUT semantics). Every active metadata key omitted from the request body is cleared. To set or clear individual keys without disturbing the rest, use patch-bill-metadata instead. Null, empty, and whitespace-only values clear a single key. Archived keys may only be cleared, never changed. Every key must name a definition assigned to bills: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. Writes are rejected with a 400 while the bill has a pending approval request. |
| `RILLET_UPDATE_CONTRACT_METADATA` | Updates contract metadata | IMPORTANT: This is a full-replace operation (PUT semantics). Every active metadata key omitted from the request body is cleared. To set or clear individual keys without disturbing the rest, use patch-contract-metadata instead. Null, empty, and whitespace-only values clear a single key. Archived keys may only be cleared, never changed. Every key must name a definition assigned to contracts: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. |
| `RILLET_UPDATE_CUSTOMER_METADATA` | Updates customer metadata | Full replacement: every active key omitted from the request is cleared. To set or clear individual keys without disturbing the rest, use patch-customer-metadata instead. Null, empty, and whitespace-only values clear one key. Unknown keys, archived keys, and definitions not assigned to customers fail the entire request with a 400. Metadata-only changes are recorded in the audit log but do not trigger customer.updated webhooks or customer integration syncs. |
| `RILLET_UPDATE_FIELD` | Updates a field | Changes labels, validation rules, or visibility metadata on an existing custom field without recreating historical values. Coordinate with stakeholders before renaming because downstream integrations often key off the human-readable label. This PUT operation sends the complete documented request representation. |
| `RILLET_UPDATE_FIELD_VALUE` | Updates a field value | Renames or reorders a pick-list entry while preserving its underlying id so historical records stay linked to the same option. Prefer this over delete-and-recreate when auditing requires stable references across reporting periods. This PUT operation sends the complete documented request representation. |
| `RILLET_UPDATE_INVOICE_METADATA` | Updates invoice metadata | IMPORTANT: This is a full-replace operation (PUT semantics). Every active metadata key omitted from the request body is cleared. To set or clear individual keys without disturbing the rest, use patch-invoice-metadata instead. Null, empty, and whitespace-only values clear a single key. Archived keys may only be cleared, never changed. Every key must name a definition assigned to invoices: an unknown key, or one assigned only to another entity type, fails the request with a 400. Keys are never silently ignored. The write is atomic: if any key fails validation, nothing is written. |
| `RILLET_UPDATE_INVOICE_SENT_STATUS` | Updates invoice sent status | Marks whether an invoice has been delivered to the customer, which downstream workflows use for collections cadence and compliance reporting. Set the sent flag true after your billing system or email provider confirms delivery, or false while the document is still internal-only. This PUT operation sends the complete documented request representation. |
| `RILLET_UPDATE_TAXES_FOR_A_CREDIT_MEMO` | Updates credit memo taxes | Refreshes tax quotes on an existing credit memo using the same structured payload as invoice tax updates, stamped with taxesCalculatedAt for auditability. Use after line items change or when your tax engine recomputes jurisdiction-specific amounts before issuing the credit to the customer. |
| `RILLET_UPDATE_TAXES_FOR_AN_INVOICE` | Updates invoice taxes | Recalculates or replaces tax lines on an existing invoice using the supplied tax payload. Use after changing taxable addresses or when integrating an external tax engine result. Returns `400` when the supplied taxes would turn an invoice total that is zero or positive into a negative total. Invoices whose total is already negative can still be updated. |
| `RILLET_UPLOAD_CHARGE_DOCUMENT` | Uploads a document to a charge | Attaches a receipt (PDF, TXT, JPG/JPEG, PNG, GIF, XLSX/XLS, DOCX/DOC, CSV, RTF, TIFF/TIF, BMP, Pages, Numbers, PPTX, or PPT) to an existing charge using multipart form data with a single file part. PDF, JPEG, and PNG keep content-signature validation and do not require a matching filename extension. Every other format requires an allowed filename extension and either a matching content type or application/octet-stream. Files detected as HTML are rejected regardless of their filename or declared content type. |
| `RILLET_UPLOAD_CONTRACT_DOCUMENT` | Uploads a document to a contract | Attaches one PDF, JPEG, PNG, or XLSX file to an existing contract. Existing attachments are preserved, including files uploaded through the Rillet application or imported from Salesforce. Repeating an upload creates another attachment. A file may be at most 9 MiB. The upload is refused when the contract already has 20 attachments, or when it would take the contract's attachments past 100 MiB in total; files uploaded through the Rillet application or imported from Salesforce count toward both limits. A file name may have at most 255 characters and must not contain a path. |
| `RILLET_UPLOAD_DOCUMENT` | Uploads a document | Attaches a document (PDF, TXT, JPG/JPEG, PNG, GIF, XLSX/XLS, DOCX/DOC, CSV, RTF, TIFF/TIF, BMP, Pages, Numbers, PPTX, or PPT) such as an invoice, contract, or receipt to an existing bill using multipart form data with a single file part. Call after the bill exists so approvers and auditors can open the evidence directly from the payable record. PDF, JPEG, and PNG keep content-signature validation and do not require a matching filename extension. Every other format requires an allowed filename extension and either a matching content type or application/octet-stream. Files detected as HTML are rejected regardless of their filename or declared content type. |
| `RILLET_UPLOAD_DRAFT_CONTRACT_DOCUMENT` | Uploads a document to a draft contract | Attaches one PDF, JPEG, PNG, or XLSX file to an existing draft contract. Existing attachments are preserved, including files uploaded through the Rillet application or imported from Salesforce. Repeating an upload creates another attachment. A file may be at most 9 MiB. The upload is refused when the draft contract already has 20 attachments, or when it would take the draft contract's attachments past 100 MiB in total; files uploaded through the Rillet application or imported from Salesforce count toward both limits. A file name may have at most 255 characters and must not contain a path. When the draft contract is confirmed, its attachments move to the contract. Re-creating the draft contract with POST /draft-contracts and the same external reference discards its attachments; use PUT to change a draft contract. |
| `RILLET_UPLOAD_INVOICE_DOCUMENT` | Uploads a document to an invoice | Attaches one PDF, JPEG, PNG, or XLSX file to an existing invoice. Existing attachments are preserved, including files uploaded through the Rillet application. Repeating an upload creates another attachment. An invoice can have at most 10 attachments totalling at most 7 MiB, including files uploaded through the Rillet application, so the invoice email stays within delivery limits. A file name may have at most 255 characters and must not contain a path. Attachments are included when Rillet emails the invoice. Attach before the invoice is sent: adding a file to an invoice that was already sent does not send it again. |
| `RILLET_UPLOAD_JOURNAL_ENTRY_DOCUMENT` | Uploads a document to a manual journal entry | Appends one PDF, JPEG, PNG, or XLSX of at most 20 MiB to an existing manual journal entry. Create the journal entry first; for asynchronous imports, wait until the entry is available. Existing attachments are preserved. Repeating an upload creates another attachment. A journal entry can have at most 10 attachments, including files uploaded through the Rillet application. Attachments may be added to approved entries and entries in closed periods without changing accounting data or approval status. System-generated and non-posting entries are not supported. |
| `RILLET_UPLOAD_REIMBURSEMENT_DOCUMENT` | Uploads a document to a reimbursement | Attaches a receipt (PDF, TXT, JPG/JPEG, PNG, GIF, XLSX/XLS, DOCX/DOC, CSV, RTF, TIFF/TIF, BMP, Pages, Numbers, PPTX, or PPT) to an existing reimbursement using multipart form data with a single file part. PDF, JPEG, and PNG keep content-signature validation and do not require a matching filename extension. Every other format requires an allowed filename extension and either a matching content type or application/octet-stream. Files detected as HTML are rejected regardless of their filename or declared content type. |
| `RILLET_UPSERT_A_USAGE_RECORD` | Upserts a usage record | Creates usage records on dates where previously no usage was recorded. Overwrites usage records on dates where usage was previously recorded already. |

## Supported Triggers

None listed.

## Troubleshooting

### 1. Why does Claude not use the Composio connector for Rillet?

The connector can show as connected, but Claude must use it in each Rillet conversation.
- Click + at the lower left of the chat, or type /.
- Hover Connectors.
- Turn on Composio.
- Ask Claude to connect to Rillet again.

### 2. Why does Claude show an MCP server error before Rillet connects?

Claude can show Couldn't reach the MCP server or Authorization with the MCP server failed when you add the connector for Rillet.
- Check that the connector URL is https://connect.composio.dev/mcp.
- Connectors run from Anthropic's cloud, so your device network is usually not the problem.
- Add the connector again from Customize > Connectors, then ask Claude to connect Rillet.
- If it fails again, send the error and the ofid_ reference id to support@composio.dev.

### 3. Why does the Rillet authorization link not work?

The Composio connector is one server. Your Rillet account connects separately when Claude asks for it.
- If the browser does not open, or the link expires, ask Claude to retry the Rillet connection.
- Composio creates a fresh Rillet authorization link.
- Open that link in your browser and finish the Rillet sign-in.

### 4. Why do Rillet actions fail after they worked before?

The Rillet connection can expire or lose permission.
- Ask Claude to inspect the Rillet connection.
- If the connection is unhealthy, disconnect it when Claude prompts you.
- Reconnect the Rillet account and retry the action.
- If Claude shows a permission prompt, approve it before Claude changes data in Rillet.
- If the action still fails with a permission error, check that the connected account has that permission in Rillet itself.

### 5. How do I switch to a different Rillet account?

Claude can manage the Rillet connection for you.
- Ask Claude to disconnect or delete the current Rillet account.
- Ask Claude to connect Rillet again.
- Open the new Composio authorization link for Rillet.
- Sign in with the other Rillet account in the browser.
- After the account connects, ask Claude to retry the Rillet task.

### 6. Why is my Rillet connection missing in Claude Desktop or on a Team plan?

The connector belongs to your Claude account, so your Rillet connection works in Claude Web, Desktop, and Cowork.
- In Claude Desktop, open Customize > Connectors.
- Next to Composio, click ⋮ and click Clear cache.
- If Rillet tools still do not appear, click ⋮, disconnect, remove the connector, and add it again.
- On Team or Enterprise, an Owner or Primary Owner must enable the connector before you can connect Rillet.

## Creating MCP Server - Stand-alone vs Composio SDK

The Rillet MCP server connects Claude Web, Desktop, and Cowork to your Rillet account through Composio. Once connected, Claude can use the available Rillet tools and triggers to complete tasks on your behalf.

## Complete Code

None listed.

## How to build Rillet MCP Agent with another framework

- [ChatGPT](https://composio.dev/toolkits/rillet/framework/chatgpt)
- [Hermes](https://composio.dev/toolkits/rillet/framework/hermes-agent)
- [Atomic Agent](https://composio.dev/toolkits/rillet/framework/atomic-agent)

## Related Toolkits

- [Stripe](https://composio.dev/toolkits/stripe) - Stripe is a global online payments platform offering APIs for managing payments, customers, and subscriptions. Trusted by businesses for secure, efficient, and scalable payment processing worldwide.
- [44API](https://composio.dev/toolkits/44api) - 44API is an API service for validating VAT and tax identifiers and returning company details. Use it to verify business tax data and manage account IP whitelists quickly.
- [Airwallex](https://composio.dev/toolkits/airwallex) - Airwallex is a global financial platform providing business accounts, payments, payouts, FX, and cards. Built to simplify cross-border payments and streamline financial operations for businesses.
- [Aiwyn Tax MCP](https://composio.dev/toolkits/aiwyn_tax_mcp) - Aiwyn Tax MCP is a tax estimation service powered by Aiwyn's federal and state tax engine. It helps teams estimate tax outcomes without building tax calculation logic from scratch.
- [Alpaca](https://composio.dev/toolkits/alpaca) - Alpaca is a stock and crypto trading platform for commission-free trading, real-time market data, and algorithmic strategies. Use it to build brokerage apps, trading bots, and portfolio workflows with market connectivity.
- [Alpha vantage](https://composio.dev/toolkits/alpha_vantage) - Alpha Vantage is a financial data platform offering real-time and historical stock market APIs. Get instant, reliable access to equities, forex, and technical analysis data for smarter trading decisions.
- [Altoviz](https://composio.dev/toolkits/altoviz) - Altoviz is a cloud-based billing and invoicing platform for businesses. It streamlines online payments, expense tracking, and customizable invoice management.
- [Benzinga](https://composio.dev/toolkits/benzinga) - Benzinga provides real-time financial news and data APIs for market coverage. It helps you track breaking news and actionable market insights instantly.
- [bexio](https://composio.dev/toolkits/bexio) - bexio is a Swiss business management platform for accounting, invoicing, contacts, projects, banking, expenses, and payroll. It brings core business operations into one connected workspace.
- [Billsby](https://composio.dev/toolkits/billsby) - Billsby is a subscription billing platform for managing customers, subscriptions, invoices, products, plans, usage counters, add-ons, and allowances. It helps SaaS and subscription teams automate billing operations without building complex billing logic from scratch.
- [Chaser](https://composio.dev/toolkits/chaser) - Chaser is accounts receivable automation software that sends invoice reminders and helps businesses get paid faster. It streamlines the collections process to save time and improve cash flow.
- [Clarity AI MCP](https://composio.dev/toolkits/clarity_ai_mcp) - Clarity AI MCP is an MCP toolkit for simulating SFDR 2.0 fund classifications from a fund name, ISIN, or CUSIP. Use it to tap Clarity AI disclosure data and modeling without building custom sustainability-data workflows.
- [Clientary](https://composio.dev/toolkits/clientary) - Clientary is a platform for managing clients, invoices, projects, proposals, and more. It streamlines client work and saves you serious admin time.
- [Coinbase](https://composio.dev/toolkits/coinbase) - Coinbase is a platform for buying, selling, and storing cryptocurrency. It makes exchanging and managing crypto simple and secure for everyone.
- [Coinbase Agents MCP](https://composio.dev/toolkits/coinbase_agents_mcp) - Coinbase Agents MCP is Coinbase's managed toolkit exposing accounts, portfolios, orders, fills, and market data. Use it to let authorized agents inspect holdings, execute trades, perform transfers, and handle payments.
- [Coinbase Wallet MCP](https://composio.dev/toolkits/coinbase_wallet_mcp) - Coinbase Wallet MCP is Coinbase's wallet service for interacting with onchain accounts. Use it to give agents secure, structured access to inspect wallets and request onchain actions.
- [Coinranking](https://composio.dev/toolkits/coinranking) - Coinranking is a comprehensive cryptocurrency market data platform offering access to real-time coin prices, market caps, and historical data. Get accurate, up-to-date stats for thousands of digital assets in one place.
- [CurrencyScoop](https://composio.dev/toolkits/currencyscoop) - CurrencyScoop is a developer-friendly API for real-time and historical currency exchange rates. Easily access fiat and crypto data for smart, up-to-date financial applications.
- [Daffy](https://composio.dev/toolkits/daffy) - Daffy is a modern charitable giving platform with a donor-advised fund. Easily set aside funds, grow them tax-free, and donate to over 1.7 million U.S. charities.
- [Debitura](https://composio.dev/toolkits/debitura) - Debitura is a debt collection platform for managing creditor cases, payments, tasks, coverage, divisions, and webhooks. It helps teams organize collection operations and track debtor activity through a Customer API.

## Frequently Asked Questions

### What are the differences in Tool Router MCP and Rillet MCP?

With a standalone Rillet MCP server, the agents and LLMs can only access a fixed set of Rillet tools tied to that server. However, with the Composio Tool Router, agents can dynamically load tools from Rillet and many other apps based on the task at hand, all through a single MCP endpoint.

### Can I use Tool Router MCP with Claude Cowork?

Yes, you can. Claude Cowork fully supports MCP integration. You get structured tool calling, message history handling, and model orchestration while Tool Router takes care of discovering and serving the right Rillet tools.

### Can I manage the permissions and scopes for Rillet while using Tool Router?

Yes, absolutely. You can configure which Rillet scopes and actions are allowed when connecting your account to Composio. You can also bring your own OAuth credentials or API configuration so you keep full control over what the agent can do.

### How safe is my data with Composio Tool Router?

All sensitive data such as tokens, keys, and configuration is fully encrypted at rest and in transit. Composio is SOC 2 Type 2 compliant and follows strict security practices so your Rillet data and credentials are handled as safely as possible.

---
[See all toolkits](https://composio.dev/toolkits) · [Composio docs](https://docs.composio.dev/llms.txt)