270710 QWILR Options Research

Date: 2026-07-10 Status: research and controlled test findings, not implemented

Question

For Deal Process V2, should Peppermint:

create Qwilr pages programmatically through the public API;
continue creating them through the standard Qwilr-Zoho integration and read the accepted result through the API; or
allow staff to build freely in Qwilr and register each page against its Deal?

The goal is to capture accepted commercial facts accurately, associate every accepted page with exactly one CRM Deal, and keep proposal creation simple for staff.

Current Conclusion

The standard Qwilr-Zoho integration can create a useful editable page, but its Deal-to-page association is not available to Peppermint middleware through the documented Zoho or Qwilr APIs.

This leaves two reliable choices:

require staff to register the resulting Qwilr URL against the Deal, with validation and exception controls; or
create the page through the Qwilr API and include the Zoho Deal ID in Qwilr metadata at creation time.

For a properly automated V2 handoff, API creation is the cleaner design. It removes the association risk but incurs Qwilr's automated-document charge. The historical volume assessment below puts that cost at approximately US$630-US$830 per year at Peppermint's recent proposal volume, depending on the billing option and actual annual volume.

This is a design recommendation for discussion, not an implemented process.

Current Account And Pricing

Peppermint has moved from the legacy Business plan to Starter.
The Starter public API token was tested successfully on 2026-07-10: GET /v1/users returned HTTP 200.
Before the controlled page test, Qwilr Usage & Credits showed:
- zero automated documents this month and in the previous 12 months;
- US$0 credits available;
- a current rate of US$5 per automated document;
- no credit expiry.
Peppermint already uses Qwilr's standard Zoho Marketplace integration to create pages from CRM records.

Published Starter rates as of 2026-07-10 are:

Starter option	Included/volume	Published cost
Pay as you go	Each automated page	US$5 per page
Prepaid bundle	125 pages, expiring after 12 months	US$500 upfront / US$4 per page when fully used

The account did not display an included Starter balance during the test, even though Qwilr's general material describes approximately ten introductory automated creations. Cost planning should therefore use the actual account rate rather than assume free creations.

Qwilr describes credits as automated creation charges. The published material does not indicate that webhook delivery or page GET requests consume credits.

Source: How credits work in Qwilr.

Confirmed Qwilr Capabilities

Accepted Editor-Built Quotes Can Be Read

Qwilr Support confirmed that a page created and edited through the Qwilr editor does not need to have been created through the public API for its accepted Quote Block to be retrieved.

After final acceptance, the page GET response exposes the accepted quote under acceptance.quote, including:

Quote Block sections and Plan Cards;
which sections and items were selected;
accepted quantities;
unit prices;
accepted totals.

Source: Qwilr quote data lifecycle.

API Creation Can Carry The Deal Identity

When the public API creates a page, Peppermint can include controlled metadata such as:

{
  "metadata": {
    "crm": "zoho",
    "module": "Deals",
    "recordId": "<zoho-deal-id>"
  }
}

That metadata is returned with Qwilr webhook events and the expanded page response. It provides a deterministic association without relying on the page name, staff memory, or a CRM related-list lookup.

Webhooks Can Start The Acceptance Handoff

The public API supports subscriptions including pageAccepted, pagePartiallyAccepted, pagePreviewAccepted, pageFirstViewed, and pageSetLive.

For an API-created page, the intended handoff can therefore be:

create the page with the Zoho Deal ID in metadata;
receive pageAccepted with the page ID, metadata, and idempotency key;
fetch the accepted page with acceptance expanded;
verify the metadata identifies exactly one Deal;
save the accepted snapshot and Deal Lines;
move the Deal to Reserved and start the Deal handoff.

Source: Qwilr API reference.

The Standard Zoho Integration Still Has Useful Authoring Features

The Qwilr Marketplace extension can create an editable Qwilr page from a Zoho Lead, Contact, Account, Deal, or Quote. It can populate CRM variables, and Zoho Products can populate Quote Block tables or Plan Cards.

These features make it a good manual authoring route. They do not, however, solve the Deal association required by an automated acceptance handoff.

Sources:

Controlled Test Findings

Peppermint created a disposable Test07 page from Zoho Deal 42659000016717012 using the standard Qwilr Marketplace action.

Qwilr Response

GET /v1/pages/6a510f81dc02a6ce186521a7 with metadata, acceptance, and previewAcceptance expanded returned HTTP 200 and exposed:

page ID and name;
draft status;
PDF, editor, public, and collaborator URLs;
Qwilr owner ID;
expiry settings.

It also returned:

metadata: null;
acceptance: null;
previewAcceptance: null.

The acceptance fields are expected to remain empty while the page is a draft. The important association finding is that standard Zoho creation did not put the Zoho Deal ID into Qwilr metadata.

The public Qwilr API also rejected GET /v1/pages with HTTP 405. It can fetch a known page ID but does not provide a documented endpoint for listing pages to discover the newest one.

Zoho Response

Zoho displayed the generated page under the Deal's Qwilr Pages related list, including its shareable, collaborator, and PDF links. The related-list metadata identified it as:

API name: qwilr__Qwilr_Pages;
type: custom_function;
href: null.

The standard Zoho Related Records endpoint could not read the list. It continued to return OAUTH_SCOPE_MISMATCH after Peppermint re-authorised the OAuth grant with ZohoCRM.functions.execute.READ and minted a fresh access token. A separate function API probe confirmed that the new function scope was active, so this was not a cached-token problem.

The related-list API name was not an executable Zoho function API name either. The Marketplace extension therefore renders association data in the CRM UI but does not expose that association through the documented CRM APIs.

The existing Deal field qwilr_link remained empty, and the extension did not create or populate a Deal-related SOW record with the new page URL.

Metadata Cannot Be Added Afterwards

The documented Qwilr page update operation supports only:

changing published state;
changing automatic link-expiry settings.

Peppermint cannot create a page through the standard Zoho integration and then patch the Deal ID into Qwilr metadata. The identity must be supplied when the page is API-created, or separately registered in CRM.

Source: Qwilr API page update.

Identification And Safety Rules

Associate The Qwilr Page With One Deal

Do not automatically match a page to a Deal using only page title, owner, amount, or timing. These values can help suggest a candidate for manual review, but none is a stable unique key.

Safe automatic routing requires one of:

an API-created page containing the Zoho Deal ID in Qwilr metadata; or
a validated CRM registration that stores the Qwilr page ID and link on exactly one Deal.

An unmatched pageSetLive or pageAccepted event should create an exception for review and must not start fulfilment or invoicing.

Associate Each Accepted Line With One Product

The support confirmation guarantees accepted selections, quantities, prices, and totals. It does not yet prove that every editor-built line contains a stable CRM Product or quote-line ID.

This creates two levels of output:

Commercial snapshot: selected sections, quantities, prices, schedules, and accepted total can be stored even without a Product match.
Automated fulfilment: project, plan, Delivery Model, and invoice routing requires a reliable Product identity or explicit manual mapping.

Position or order matching is too fragile when staff can add, remove, or rearrange items in the Qwilr editor.

Options Comparison

Option	Creation cost	Staff workflow	Deal identification	Assessment
Standard Zoho integration plus manual page registration	Creation charge still to confirm	Existing creation flow plus one controlled paste/registration	Reliable only after registration	Viable lower-cost/manual path, but omissions need blocking and exception controls
Staff create freely in Qwilr plus manual registration	No API creation charge	Highest freedom plus registration	Reliable only after registration	Supported exception path
Public API creates the page with Deal metadata	US$5 PAYG or prepaid bundle	Can be reduced to one CRM action; staff edit the generated page	Deterministic at creation	Preferred architecture for a fully automated V2 handoff

Historical Proposal Volume And Cost Assessment

Method

On 2026-07-10, Peppermint queried the live Zoho DealHistory module and selected history rows where Stage was exactly Proposal.

The base case counts each Deal once per calendar year, even if it moved out of and back into Proposal. This approximates one created Qwilr page per Deal.

Period	Valid `Proposal` history entries	Unique Deals	Repeat entries excluded from base case
2025 full year	177	151	26
2026 to 10 July	91	87	4

One additional 2026 history row had no Deal lookup and was excluded. The 2026 period covers 191 days. A simple annualised run rate is approximately 166 unique Deals for 2026.

Estimated Automated-Creation Cost

The prepaid calculation assumes one 125-page bundle is used first and any pages beyond it continue at the US$5 PAYG rate shown by Qwilr. The bundle is not a general US$4 PAYG rate: it costs US$500 upfront and expires after 12 months.

Scenario	Estimated pages	PAYG at US$5	Lowest simple bundle/PAYG mix
2025 observed	151	US$755	US$630: one bundle plus 26 PAYG pages
2026 through 10 July	87	US$435	US$435 PAYG; a US$500 bundle is not yet cheaper
2026 simple annualised run rate	166	US$830	US$705: one bundle plus 41 PAYG pages

If every repeat entry into Proposal created another page, the sensitivity is:

2025: 177 pages, US$885 PAYG or US$760 with one bundle plus PAYG;
2026 to 10 July: 91 pages, US$455 PAYG.

The observed and annualised base cases indicate a likely annual cost of roughly:

US$755-US$830 using PAYG only; or
US$630-US$705 using one prepaid bundle plus PAYG at this volume.

That is approximately US$53-US$69 per month when spread over a year. At an internal labour value of US$100 per hour, a US$4-US$5 page charge breaks even if the integrated workflow saves only about 2.5-3 minutes per proposal. This does not include the additional value of preventing an accepted page from being associated with the wrong Deal or left unmatched.

Assessment Limits

The cost estimate assumes one page per unique Deal reaching Proposal.

It can be understated when:

multiple new Qwilr pages are created for alternatives or revisions on one Deal;
a Deal starts after Proposal but still receives a Qwilr page;
pages are created from Quotes, Contacts, Accounts, or Leads instead of Deals.

It can be overstated when:

a Deal reaches Proposal without a Qwilr page;
an old page is reused rather than creating a new one.

The estimate is in USD and excludes currency conversion, tax, and any regional billing treatment.

Recommendation For Discussion

For a fully automated Deal Process V2, use API page creation with the Zoho Deal ID embedded in Qwilr metadata.

The expected annual metered cost is modest relative to the reliability gained:

every webhook can resolve directly to one Deal;
staff do not need to remember a separate registration step;
unmatched acceptance becomes an exception rather than normal operation;
the proposal workflow only needs to save a few minutes per Deal to recover the fee.

The standard Zoho integration can remain available for exceptional or manually managed proposals, but those pages must be registered against a Deal before they can participate in automated acceptance, fulfilment, or invoicing.

Before committing, discuss with Lou whether avoiding the annual creation cost is worth introducing a mandatory registration step and exception queue into the sales workflow.

Remaining Controlled Test

The identity experiment is complete. The remaining test should focus on the accepted commercial payload:

Check whether the standard Zoho-created Test07 page changed Usage & Credits.
Add representative one-off, recurring, Plan Card, optional, quantity, discount, tax, and manually edited lines.
Subscribe a disposable endpoint to pagePreviewAccepted and pageAccepted.
Complete preview acceptance and final acceptance.
Fetch the accepted page with acceptance and metadata expanded.
Record selected sections, item identity, quantity, unit price, billing schedule, discount, tax, currency, and totals.
Confirm which accepted lines retain stable Product identity and which need manual mapping.
Replay the same acceptance event and confirm the proposed importer would create no duplicates.

Deliberate Limits

This note confirms API authentication, draft page retrieval, the absence of metadata on a standard Zoho-created page, and the inability to retrieve the extension's custom-function related list through the documented Zoho API.

It does not yet confirm:

whether standard Zoho-created pages consume an automated-creation credit;
the exact accepted payload returned by Peppermint's current templates;
whether editor-built lines expose identifiers sufficient for automatic Product mapping;
the final AUD amount invoiced for Starter automated page creation.

No V2 Qwilr creation, webhook, Deal Line, fulfilment, or invoicing automation is implemented by this research note.