Quote leads can leave Request a Quote and Hide Price through a public REST API and through webhooks. The API uses a bearer token. The catalog lists both, and it lists the whole app as fully free, including the API. A developer on your side uses that access to copy a quote into the system you already run.
HubSpot, Klaviyo, and Mailchimp are not in this app’s catalog. There is no native connector to those products to turn on, and there is no published field map in the catalog to paste into a CRM. A connection your developer builds with the API or a webhook is your integration. It is not a connector the app ships.
What the catalog actually exposes
The additional features section of the catalog states a public REST API with webhook support, authenticated by a bearer token, for merchants who want to integrate quotes with their own systems. That is the verified surface. It does not name the paths, the event names, or the JSON fields. Those details belong in the credential screen and any docs inside the app when you install it. This article will not invent them.
- REST API: bearer-token access so your system can work with quotes.
- Webhooks: the catalog says webhook support is part of that public API.
- Audience: your own systems, built by your team or a developer you hire.
- Price: included with the free app. The catalog has no paid tier for the API.
Inside the app, quotes already have a list, filters, statuses, a CSV export, and an activity log. CSV export includes quote number, customer name, email, phone, status, totals, discount, shipping, tax, and due or expiry dates, filtered by status and date range. Use CSV when a person needs a file. Use the API or webhooks when another system should receive the quote without that download.
A developer-built connection is not a native connector
Native, in this context, would mean a switch for HubSpot, Klaviyo, or Mailchimp that creates the contact for you. The quote catalog does not include those switches. If a quote should become a contact in one of those tools, someone has to build and maintain that step: read the quote from the API or receive the webhook, then call the other product with the account you own there.
That project needs a field mapping you write down yourselves. The catalog does not say which quote properties exist on the wire, so the mapping starts from a real payload you capture in a test, not from a guessed list of columns. Map only the fields you see. Store the bearer token as a secret. Rotate it if it is copied into a ticket or a chat.
SK Form Builder is a different Squadkin app. Its catalog includes its own connectors. Those connectors do not move a quote from this quote app. Installing the form app does not add HubSpot, Klaviyo, or Mailchimp to Request a Quote and Hide Price.
Choose CSV, the API, or a webhook for the right reason
CSV export is the path for a person. Filter by status and date range, then download quote number, customer name, email, phone, status, totals, discount, shipping, tax, and due or expiry dates. That file is enough for a weekly review. It is a poor feed for a system that should know about a quote within minutes.
Use the REST API when your system asks for quotes on its own schedule, with the bearer token on the request. Use webhooks when the app should notify your endpoint that something happened. The catalog states that both exist. It does not name which quote events emit a webhook, so subscribe in a test shop and record the events you actually receive. Build the handler for those events. If a status you care about never arrives, the in-app list is still the source you can export, and you should say so in your own runbook.
Store the token in a secret your server can read. Do not place it in theme code, in a storefront metafield, or in the quote email. Log the quote identifier your endpoint saw, and keep a retry for deliveries your server failed to accept. A developer-built retry is your operations work. The catalog does not describe a replay button.
What a serious test looks like
Create a quote on a development store or with a clearly named test customer. Trigger the webhook or call the API with the bearer token. Capture the payload your endpoint receives. Confirm it is the test quote, then send one accepted quote and one rejected quote if both events matter to you. Write down which statuses you observed. The in-app statuses include Pending, Opened/Sent, Sent, Accepted, Rejected, and Ordered. Whether each of those fires a webhook is something you confirm from the payload, because the catalog does not list the events.
- Keep the token out of the storefront theme and out of email.
- Log failures on your endpoint so a missed quote is visible.
- Compare one API record with the same quote in the admin before you trust the mapping.
- Do not describe the result as an official HubSpot, Klaviyo, or Mailchimp integration.
Merchant email still goes out from the app, with uploaded files attached to that email. The API is an additional path for your systems. It does not replace the merchant notification unless you deliberately stop relying on the inbox.
Questions about the quote API
Does the quote app include HubSpot, Klaviyo, or Mailchimp?
No. Those connectors are not in the quote catalog. The documented way out is the bearer-token REST API and webhooks.
Is there a published field map?
The catalog does not publish one. Capture a real response from your store and map the fields you receive.
Is the API on a paid plan?
The catalog includes the public API and webhooks in the free app. There is no paid tier listed for this product.
Use the API or a webhook for the system you own, and keep CRM connectors off the requirements list for this app. The product page is Request a Quote and Hide Price. The listing is Request a Quote and Hide Price.