Rillet is an ERP that automates accounting workflows, including revenue recognition, close management, reporting, accounts receivable, and accounts payable.
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.
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.
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.
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.
Create a charge
Create a reimbursement
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Records a cash payment that settles all or part of a reimbursement.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Permanently deletes a customer. Verify no active contracts or open invoices reference this customer first.
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.
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.
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.
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.
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.
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.
Permanently removes a product or bundle. Ensure no in-flight contracts or invoices require this product before deleting.
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.
Reverses an uncleared reimbursement payment that was recorded in error.
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.
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.
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.
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.
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.
Dissolves the grouping. Every member becomes a standalone customer; no customer is deleted.
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.
Return the organization associated with the connected Rillet credentials, including its ID, currency, timezone, and trade name.
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.
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.
Returns the payment method configured for auto-payment for the given customer.
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.
Return one page of bank transactions, optionally filtered by bank account, subsidiary, transaction-date range, or update time.
Return one page of bills, optionally filtered by subsidiary, vendor, payment status, or update time.
Return one page of contracts, optionally filtered by subsidiary, customer, lifecycle status, or inclusive/exclusive start and end date ranges.
Return one page of accounts-receivable customers, optionally filtered by name, external reference, or update time.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Returns sellable products and services for accounts receivable (contracts, invoices). Supports pagination and optional filters such as status, currency and type.
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.
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.
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.
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.
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.
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.
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.
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.
Returns journal entries with line item amounts converted to the reporting currency.
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.
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.
Lists payments recorded against a reimbursement so external systems can reconcile its paid balance.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Computes and returns the invoice schedule the given contract would produce, without creating the contract or persisting anything.
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.
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.
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.
Updates the details the bundle keeps for each component product to the products' current values. Contracts that already sold the bundle don't change.
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.
Changes the family's name. Membership is untouched: anything else in the body is ignored, so use the members endpoints to change who belongs.
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.
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.
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.
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.
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.
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.
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.
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.
Returns a single customer record including billing profile details, which are needed for updates.
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.
Returns a draft contract by id, including its line items and any attached external references.
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.
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.
Returns a single product or bundle definition, including pricing configuration used on contracts and invoices.
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.
Returns one subsidiary by id for the authenticated organization. Call list-all-subsidiaries first if you need to resolve which subsidiary id to use.
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.
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.
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.
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.
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.
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.
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.
Returns a cash flow statement report for the specified date range.
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.
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.
Returns an executive profit and loss report with margins for the specified date range.
Returns an income statement (profit and loss) report for the specified date range.
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.
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.
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.
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.
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.
Removes every application from this credit memo, reverting all invoice allocations.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Creates usage records on dates where previously no usage was recorded. Overwrites usage records on dates where usage was previously recorded already.
The Rillet integration connects your Dench AI CRM directly to Rillet, so agents can read and act on your Rillet data as part of everyday work — answering questions in chat, keeping your CRM in sync, and running automations without anyone copying data between tools.
174 actions are available for agents to invoke on your behalf. Every call runs through Rillet's own authorization, scoped to the account you connect.
Sign in to your Dench workspace and open Integrations.
Find Rillet and click Connect — you'll authorize access through Rillet's own sign-in flow. No API keys or code required.
Ask an agent to use Rillet in chat, or call it from an automation.
Manage or disconnect the connection any time from workspace settings.
The Dench Rillet integration connects your AI CRM to Rillet, so AI agents can work with your Rillet data as part of chats, automations, and CRM workflows. You connect your account once, and every agent in your workspace can use it — governed by your workspace permissions.
The Rillet integration currently exposes 174 actions, including Adds members to a customer family, Amends a contract, Applies a vendor credit to bills, Completes a close checklist task, Create a charge, and Create a reimbursement. Agents invoke them on your behalf from chat or from automations.
No. You connect Rillet from your Dench workspace using Rillet's own sign-in and authorization flow — no API keys to copy, no glue code to maintain.
Connections are authorized through Rillet's own authentication flow, and Dench stores only the authorization needed to act on your behalf. You can review and disconnect the Rillet connection from your workspace settings at any time.