Connect Cuevr to other tools
Cuevr connects to your tools through an API v1 and webhooks. Create a key, receive events and keep your proposals in sync with your CRM.
Guide chapters14 of 15
On this page6 sections
Understand the scope
Cuevr connects to your tools through an API v1 and webhooks, which you can use from Make, n8n or Zapier, among others. In one direction, Cuevr notifies your tool at every key moment of a proposal; in the other, your tool acts on Cuevr with an access key: creating a client or a proposal from a deal, closing or reopening the deal, reading the qualification.
Management features are in Admin, Organization tab, Integrations card, with an owner or administrator role. A member sees the card but can neither create a key nor add a destination.

Create and manage an access key
- In Access keys, click Create an access key and give it a clear name.
- In What the key can do, choose the permissions your workflow needs. Everything Make or n8n needs ticks all the permissions, None unticks them.
- Click Create the key, then copy it when it is displayed: it will only be shown once.
- Test the connection with the key verification route.
- To replace a key, use Renew the key in the “…” menu of its row: Cuevr creates a new key with the same permissions, and the old one keeps working for the period shown in the confirmation window, long enough to replace it in your scenario.
- Revoke the key with Revoke the key when it is no longer used or if it has leaked: it stops working immediately.
| Permission | Label in Cuevr | Use |
|---|---|---|
clients:read | Read clients | View clients. |
clients:write | Create and edit clients | Create, rename or link a client to your CRM. |
proposals:read | Read proposals | View proposals. |
proposals:write | Create and edit proposals | Create a proposal from a deal, close or reopen the deal. |
qualification:read | Read qualifications | View a proposal’s qualification. |
qualification:write | Write in qualifications | Add the deal’s notes to the qualification at creation. |
webhooks:manage | Manage delivery destinations | Manage destinations and how they operate. |
The key starts with cuevr_. To receive a family of events, the key that subscribes a destination must also have read permission for that family. When a member leaves the organization, or is no longer an administrator, the keys they created are revoked.


Add and manage a webhook destination
- Click Add a destination, paste the Address provided by your scenario and, if you wish, a label.
- In What Cuevr sends, select the events you need.
- Tick Include reader data only if your tool must receive the prospect’s email and name.
- Click Add the destination, then copy the signing secret: it will only be shown once.
- Run Send a test from the destination’s “…” menu; the technical event is
cuevr.ping. - Follow the Delivery log. If there is an error, fix the receiver, test again, then use Turn back on if the destination was turned off.
The organization can have up to 10 destinations. The response timeout is 10 seconds. Only an HTTP 2xx status counts as delivered. URLs must use HTTPS. On failure, Cuevr retries several times at increasing intervals, then turns the destination off after repeated failures; the cause is shown under its name. Events that occur while a destination is turned off are not caught up when it is turned back on. A failed test does not count against the destination. The delivery log is kept for 30 days.
The “…” menu also offers Edit, Turn off and Delete. When a member leaves the organization, the destinations they created are turned off; you can turn them back on.

Verify the signature of deliveries
Cuevr signs every delivery in the X-Cuevr-Signature header: an HMAC-SHA256 signature of the timestamp (X-Cuevr-Timestamp header) and of the body, computed with the destination’s secret. Have your receiving tool verify this signature before processing a delivery.
Renew the secret, in the destination’s “…” menu, creates a new secret. During the period shown, every delivery is signed with both: the new one in X-Cuevr-Signature, the old one in X-Cuevr-Signature-Previous. Paste the new secret into your scenario before the end of that period.
The twenty-one available events
Fifteen events are ticked by default when a destination is created:
| API event | What it reports |
|---|---|
proposal.created | A proposal was created. |
proposal.published | A version of the proposal was published. |
proposal.sent | The proposal was sent to a named recipient. |
proposal.reshared | A proposal was reshared by a reader. |
proposal.viewed | A new reading session. |
proposal.read_seriously | A proposal was read in depth. |
proposal.signature_opened | The signature form was opened. |
proposal.signed | An acceptance or signature was recorded. |
proposal.declined | A prospect decline was recorded. |
proposal.signature_revoked | A signature was revoked by your team. |
proposal.outcome_changed | The sales outcome changed. |
proposal.outcome_cleared | The outcome was cleared when the deal was reopened. |
qualification.completed | The deal left the Qualification stage; sent once, not on every note change. |
client.created | A client was created. |
client.updated | A client was updated. |
Six events only go to the destinations that tick them:
| API event | What it reports |
|---|---|
proposal.options_changed | A reader changed the quote options. |
signal.heat_level_up | Strong comeback dashboard signal. |
signal.proposal_never_opened | Proposal never opened dashboard signal. |
signal.proposal_inactive | Proposal inactive dashboard signal. |
signal.proposal_to_close | Proposal to close dashboard signal. |
signal.dropped_proposal_reactivated | Dropped deal woke up dashboard signal. |
A signature does not, on its own, record a sales outcome. Handle signature events and outcome change events separately.

What the API lets you sync
The routes cover key verification and the event catalog, viewing and managing clients, viewing proposals and creating them from a deal, closing and reopening the deal, reading the qualification, and managing, testing and logging webhooks. Publishing and signing remain actions done in Cuevr.
When a proposal is created from a CRM, the deal’s notes are kept as is at the top of the qualification and the language given is kept. The external source + external ID pair lets you replay creations without creating a new deal on each attempt. The owner email coming from the CRM must match a member of the organization. During the trial, a proposal created by the API counts toward that member’s trial proposals.
With an inactive subscription, access becomes read-only, with exceptions for turning off or deleting a destination and revoking a key. The key’s permissions and the member’s permissions still determine what is allowed.
A question this chapter doesn’t answer?
Write to the team: a person will reply by email.