API operations.

What CIS Manager charges the authenticated user, across every tenant they own (no tenant in the route): the billing profile (invoice address and mandate state), the direct debit mandate with its GoCardless setup (start a setup, send the customer to GoCardless, complete it), the invoices with their PDFs, and the usage not yet invoiced. Reads refresh the mandate and pending payments from GoCardless.

Connections between two CIS Manager tenants (Interlinks), one resource seen from the viewing tenant's side: direction is relative to the viewer (Out = sharing CIS details to send invoices, In = receiving them). A tenant initiates a connection for one of its contacts and emails the other party; the other party accepts by setting its side (a contact created from the shared details, or an existing one), which connects both; a pending connection sent to a tenant can be rejected, any other deleted. No module gate.

Manage a tenant's contacts: the people and organisations it does business with, in one or more roles. Customers are invoiced by the tenant, suppliers invoice the tenant, and CIS subcontractors are suppliers paid under the Construction Industry Scheme. One contact, one code, whatever its roles; filter the list with role. A subcontractor carries its CIS identity (UTR, NI number, company number), invoice defaults and the current HMRC verification, and must be verified with HMRC before payments can be processed.

The tenant's email signature, whether statements are emailed automatically, and the templates of the emails it sends (one per type, customised with PUT, back to the default with DELETE).

The caller's shareable HMRC gateway credentials, under /me: a user who manages several tenants keeps one set here and points each tenant's HMRC settings at it. Passwords are never returned.

The tenant's HMRC gateway settings for CIS submissions (contractor module only): sender, references, test flags and agent details, or a reference to one of the owner's shared credentials. Passwords are never returned; a PUT without one keeps the stored one. A test sends a dummy verification through the gateway.

Purchase invoices (received from suppliers and subcontractors, paid by the tenant; contractor module) and sales invoices (issued to customers; subcontractor module), numbered in sequence per direction. Lines are part of the invoice; totals, VAT applicability and a purchase invoice's CIS deduction are computed. Payments are a child of the invoice and drive its paid state; a purchase invoice's payments must fall in a tax month whose CIS return is not yet submitted. A monthly analysis serves charts. Webhooks: invoice.created, invoice.updated, invoice.deleted.

The authenticated user: profile, application roles and the tenants they are a member of, with the user's access level and each tenant's modules; and what reaches them by email: their verification link, invitations to join tenants and connection links. Works identically with an API key (the key's owner) and a bearer token; a bearer token whose subject is new signs the user up on first use.

Free-text notes recorded against a contact, as a child of the contact: a date (what the note is about, defaulting to when it was written), the text, and who wrote it (recorded, not exposed). Any contact of the tenant can carry notes.

Remittance advices (contractor module only): what the tenant paid one subcontractor between two dates, invoice by invoice, with the CIS deductions taken. An advice is built from the payments when asked for and lives under the contact, identified by its from and to dates, with its PDF and the emails sent of it. The tenant's layout settings (columns, custom texts) are under /settings.

CIS monthly returns (CIS300; contractor module only), one per tax month (the 6th to the 5th), identified by the calendar year and month the tax month ends in. An Open return collects the subcontractor invoices paid in its month; its totals, invoice and subcontractor counts and a per-subcontractor breakdown follow the payments. The submission child sends it to HMRC (POST), which is polled in the background until HMRC accepts it or reports errors (translated onto the return), and re-opens an accepted return (DELETE). Webhooks: return.submitted, return.accepted, return.failed, return.opened.

Supervision, Direction and Control statements (contractor module only), as a child of the subcontractor: questionnaires the tenant sends a subcontractor to complete and sign on a public page, recording their employment status under the CIS rules. Creating one emails the request; the statement is pending until signed, and the contact's lastSdc follows its completed statements.

CIS payment and deduction statements (contractor module only): what one subcontractor was paid and had deducted in a tax month, or in a tax year (the annual statement). A statement exists once one of the subcontractor's invoices is paid in the period and lives under the contact, with its PDF and the emails sent of it; the tenant-wide list gives every subcontractor's statement for a period, with a combined PDF.

The tenant's members (the users who belong to it), its owner, and the invitations it has sent by email. The owner cannot be removed; ownership is transferred to another member.

The tenants (organisations) the authenticated user is a member of: the {tenant} code used in every other route, the tenant's modules, contact and VAT details, and its dashboard counts. A tenant the caller is not a member of is not found. Also creating a tenant, replacing its details (a changed email address is re-verified), its logo, its own CIS details as a subcontractor, the data-config export and import, and the caller's tenant summaries.

A CIS subcontractor's verification with HMRC, as a child of the contact (contractor module only). The verification is the outcome: not verified, entered manually (PUT), obtained from HMRC, or failed with HMRC's errors. Asking HMRC is a separate child, hmrc-request: POST submits a verify or match request, which is polled in the background, and the outcome lands on the verification; POST again while it is delayed to resume polling, DELETE to cancel it. Webhooks report each outcome (subcontractor.verified, subcontractor.verification_failed, subcontractor.verification_removed).