REST API for RISE CRM

The MCP endpoint only accepts POST. Server-Sent Events streaming is not offered, so a GET request answers with the JSON-RPC "method not found" error telling the client to POST its JSON-RPC 2.0 payloads instead.

Lists the configured webhook subscriptions, newest first. The signing secret is never part of a read response; only the has_secret flag tells you whether one is set.

Returns one webhook. The signing secret is never returned here - it is shown once, when the webhook is created or when its secret is rotated.

The delivery history of one webhook, newest first: one row per attempt, with the HTTP status code, the attempt number, a snippet of the response body, the error reason when there was one, how long the attempt took and when it ran. Blocked deliveries are logged too, with the SSRF reason in error_message.

A row appears here when an attempt is actually made, which is when the RISE cron job drains the delivery queue - not at the moment the CRM produced the event. An empty log right after a change in the CRM usually means the cron job has not run yet.

Only the most recent 500 attempts of a webhook are kept; older rows are pruned automatically.

The authoritative list of names a webhook can subscribe to. It is derived from the REST resource surface of this RISE installation, so it always matches the resources that really exist: every writable resource contributes <resource>.created, <resource>.updated and <resource>.deleted.

Three subscription shapes are accepted: the exact event name (invoices.created), the resource wildcard (invoices.*, every event of that resource) and the global wildcard (*, every event of every resource). The read-only activity log resource emits nothing, since it is itself an audit trail of the other resources.

The endpoint an n8n, Zapier or Make polling trigger calls on a schedule. Returns the records of one resource that were created - or, where RISE tracks it, changed - on or after the cursor, newest first.

How to drive it: on the first run send no cursor, which returns the last 24 hours. On every later run send back the meta.next_since value from the previous response. That value is the RISE server clock read at the start of the request, so nothing written while the query ran can fall between two polls. De-duplicate on the id field: the cursor is inclusive and some RISE columns store a date without a time, so a record can legitimately come back twice. meta.has_more only means the page came back full, so older matches may have been cut off. Do NOT re-poll with the same cursor expecting the next page - the query is not offset-paged, so an identical request returns the identical page. Raise limit, or poll more often so a window never fills.

On updates: RISE has no generic modified timestamp. A resource whose table carries a column that moves when the record is touched (a ticket's last activity, a task's status change, an invoice's cancellation) is polled on those columns too. meta.detects_updates says whether that is the case, and meta.cursor_fields lists exactly which columns were compared, so a connector can label its trigger honestly rather than promise updates it will not receive.

All timestamps in and out are UTC, which is what RISE stores. A cursor sent without an offset is read as UTC. An empty result is a normal 200 with an empty data array, never a 404, so a polling trigger does not have to treat "nothing happened" as an error.

Discovery endpoint for a polling trigger. Returns every RISE resource that can be polled by timestamp, together with the path to poll it, the columns the cursor is built from, the field to de-duplicate on, and whether the resource can detect updates as well as new records. Call this once when building the connector: the list is derived from the live REST resource catalogue and the live database schema, so it stays correct as RISE and the plugin change. Resources with no date column at all (small lookup tables such as taxes, items and labels) cannot be polled by timestamp and are reported under meta.not_pollable instead - read those through their own REST endpoints.

Returns one representative record for the resource - the most recent one - so an automation platform can show the user a real payload and let them map fields onto later steps. When the resource holds no records yet the endpoint still answers 200 with an empty field map built from the live table definition, so field mapping works on a fresh install; meta.source says which of the two you got ("record" or "schema"). The field list in meta.fields gives each returned column with its SQL type. Credential and sensitive columns are stripped exactly as they are everywhere else in this plugin, so they appear neither in the record nor in the field list.

Returns an OpenAPI 3.0 document that describes every endpoint of the REST API for RISE CRM: list, get by id, search, create, update and delete for each resource, plus the miscellaneous helper endpoints. Import the URL into Swagger UI, Postman, Insomnia or n8n to get a ready made client without writing anything by hand. The server URL is detected from the installation, so it already contains /index.php when your RISE installation is routed that way.

Renders the interactive API playground: a single self-contained HTML page that lets you try every endpoint of this installation from the browser. The endpoint catalogue is built at runtime from /api/openapi.json, so it always matches the routes this installation really exposes.

The page is a static shell - it carries no CRM data and no token - so it is served without the authtoken header, which a browser cannot send when you navigate to a URL. Paste a token into the toolbar and press Load endpoints: the token is kept in the page's memory only (never in a cookie, localStorage, sessionStorage or the URL, and gone the moment you reload or close the tab) and is attached as the authtoken header to the specification fetch and to every request you send from the page. Requests reach the very same endpoints as any other client, so writes really do change live data - non GET requests ask for confirmation first.

No CSS, JavaScript or font is loaded from a third party host, and the page is served with a Content-Security-Policy that allows code only from the document itself and network calls only back to this installation.

Returns a ready to import Postman v2.1 collection covering every endpoint registered under the api route group. The collection declares two variables, {{base_url}} (pre-filled with this installation URL) and {{authtoken}} (intentionally left empty - paste your own token after import). Collection level auth sends {{authtoken}} as the authtoken header on every request. Requests are foldered by apidoc group and carry the endpoint description plus a sample JSON body built from the documented body parameters. Routes registered with $routes->add() answer any HTTP verb; they are exported once as GET and labelled (any verb). Any route line the generator cannot read is listed in a trailing ! Unparsed routes folder instead of being dropped silently.

Renders a self-contained Swagger UI page wired to /api/openapi.json. Swagger UI itself is loaded from the jsDelivr CDN, so the browser needs outbound access to cdn.jsdelivr.net. This page is a static HTML shell: it carries no CRM data and no token, so it is served without the authtoken header (a browser cannot send one when you navigate to a URL). The toolbar at the top of the page accepts an authtoken which is kept in the page's memory only - it is never written to cookies, localStorage or sessionStorage - and is injected as the authtoken header on every request Swagger UI makes, including the OpenAPI document fetch. Every endpoint you call from the page is still protected by the normal token check.

Discovery endpoint for a dashboard or BI tool. Returns every reporting endpoint this plugin exposes, the query parameters each one accepts and the shared date range rules, so a client can build its panels without hardcoding the catalogue.

meta.max_groups is the largest page a grouped list will return. The reports that expose limit and offset page their list with it, and every report that caps a list reports the cap through its own meta.truncated map, so nothing is ever dropped in silence.

Billing performance over a date range. The range is applied to the invoice bill_date, so "invoiced" is what was billed in the window. Two payment figures are returned because they answer different questions: paid_against_invoices is what has been collected against the invoices billed in the window whenever the money arrived, while received_in_range is what actually landed in the window whatever it was billed against. A cash flow chart wants the second; an aged debt figure wants the first.

Outstanding is the unpaid remainder of the not_paid invoices in the window. Draft, cancelled and credited invoices are counted and reported but contribute nothing to outstanding, exactly as in the RISE invoice screens. Overdue applies the same tolerance the CRM uses, so a rounding cent does not keep an invoice on the overdue list.

The timeline array carries one entry per calendar month touched by the range, with both what was billed and what was received in that month, ready to plot without further aggregation. It is capped at 24 months, which the 366 day range limit already keeps out of reach, and the cap reports itself through meta.truncated.timeline so a shortened timeline can never pass for a complete one.

Delivery throughput over a date range: how many projects were opened, how many tasks were created, and how many tasks reached a done status inside the window. Task completion is read from tasks.status_changed_at, the only completion timestamp RISE keeps, and done is resolved through task_status.key_name so custom statuses are handled correctly.

Projects are counted on their created_date. RISE stores no project completion timestamp, so the status split under projects describes the current status of the projects created in the window rather than transitions that happened during it. open_now and overdue_now under tasks are likewise live snapshots and deliberately ignore the range.

Project state is read from projects.status_id joined to the project_status table, which is what the RISE application writes and filters on. projects.by_status keeps the four named buckets open, completed, hold and canceled that RISE ships with, so an existing dashboard is unaffected; projects.statuses carries the full split, one entry per project status actually in use, with its id, its stable key and its human readable title translated the way the project screens translate it. An installation that added its own status sees it in statuses and in created, but in none of the four named buckets, so read statuses to stay future proof. key_name falls back to project_status.title_language_key because RISE seeds Hold and Canceled with an empty key_name.

by_project ranks the busiest projects in the window by tasks created, with the completions for the same project, which is what a delivery dashboard plots as a leaderboard. It is a paged list: limit and offset select the page, and data.pagination reports limit, offset, returned, truncated and next_offset. truncated true means more projects match, and next_offset is the offset that returns the following page. The figures under projects, tasks and milestones are whole range aggregates and never change with the page.

A single snapshot of the CRM as it stands right now: how many clients, leads, contacts and team members exist, how projects and tickets are split by status, how many tasks are open or overdue, and the invoiced, paid and outstanding money totals. This is the endpoint behind a dashboard's top row of tiles - it takes no date range, so the numbers are always "as of now" and never depend on the caller's window.

Soft-deleted records are excluded everywhere. Leads and clients share the clients table and are separated by the is_lead flag. Contacts and team members share the users table and are separated by user_type. Task completion is resolved through task_status.key_name = 'done', so a renamed or extra status is still classified correctly. Invoice money covers documents of type 'invoice' only.

Project state comes from projects.status_id joined to the project_status table, the pair the RISE application itself writes and filters on. The named fields open, completed, hold and canceled are the four statuses RISE ships with and are kept for existing dashboards; because an installation may rename them or add its own, data.projects.statuses carries the complete split with the status id, its stable key and its human readable title. A custom status is counted in data.projects.total and in statuses, but in none of the four named fields, so a client that wants to be future proof should read statuses rather than the named fields. RISE seeds Hold and Canceled with an empty project_status.key_name, so key_name falls back to project_status.title_language_key and is therefore always populated on a stock install. The title is translated exactly as the project screens translate it.

Time logged over a date range, grouped by team member, project, task or day. Timesheets live in the project_time table, and the duration of an entry is what RISE itself computes: the difference between start_time and end_time plus the manually entered hours column. Totals therefore match the CRM's own timesheet screens to the second.

The range is applied to start_time, which RISE stores in UTC, so a caller that reports in a local timezone should shift its window accordingly. A running timer has no end_time yet and contributes nothing until it is stopped.

Every group carries both total_seconds and hours: seconds are exact and safe to sum further, hours are rounded to two decimals for display. Groups are returned largest first, except for group_by=day which is returned in date order so it can be plotted directly. Ordering is fully deterministic - ties are broken on the group key - so paging never repeats or skips a group.

The groups list is paged, identically for all four groupings. limit selects the page size, at most 200, offset selects the page, and data.pagination reports limit, offset, returned, truncated and next_offset. truncated true means more groups match the request and next_offset is the offset that returns the following page; truncated false means the list is complete. This matters most for group_by=day, because the range may be up to 366 days long while a page holds at most 200 days: such a request answers with the first 200 days, truncated true and next_offset 200, and never drops the remainder without saying so. data.totals is computed over the whole range by its own aggregate, so it is the same on every page and always exact.