How to Send Email From Better Proposals With Volanea

If you need to send email from Better Proposals when a proposal is signed, paid, created, or opened, the reliable route is an automation workflow rather than a native Volanea plugin. Better Proposals supports Zapier-based proposal triggers, and Zapier can pass the resulting proposal data to Volanea’s REST email API.

This matters because Better Proposals does not provide a native Volanea app, marketplace listing, or direct outbound-webhook configuration that you can point at an email API. Instead, Zapier is the integration layer: Better Proposals supplies the proposal event, Zapier maps and validates the data, and Volanea performs the transactional send.

The example in this guide uses the Proposal Signed trigger to send a signed-proposal confirmation to the signer. The same architecture works for internal alerts, payment acknowledgements, onboarding messages, and proposal-view follow-ups. The important part is choosing the correct Better Proposals event, mapping only fields that are actually present, and making retries safe.

What this integration does

The workflow has three distinct systems, each with a separate responsibility:

1. Better Proposals records the proposal lifecycle event, such as a proposal being created, signed, paid, or opened.
2. Zapier polls Better Proposals for the selected trigger and runs the workflow when it finds a new matching proposal record.
3. Volanea receives a server-to-server POST /v1/send request and sends the transactional email through your verified sender identity.

That separation is useful. Better Proposals remains the system of record for your proposal; Volanea remains the email delivery system; Zapier handles the translation between them.

For a signed-proposal confirmation, the practical flow is:

Client signs a Better Proposals proposal
        ↓
Zapier finds the new Proposal Signed event
        ↓
Zapier maps proposal fields into an email request
        ↓
Volanea POST /v1/send sends the confirmation
        ↓
Signer receives the transactional email

Do not treat this as a replacement for Better Proposals’ own proposal-delivery email. It is an automation for a separate transactional message that follows a proposal event. Good examples include a “we received your signed proposal” note, a next-steps email, a notification to an account manager, or a payment-instructions email after signature.

The real Better Proposals trigger to use

For this guide, select Better Proposals → Proposal Signed as the Zap trigger. Zapier describes this trigger as firing when a proposal is signed. Better Proposals also exposes Zapier triggers for New Proposal and Proposal Paid; Zapier’s Better Proposals listings additionally show workflows based on proposals being sent and opened.

The right trigger depends on the message you are automating:

Why Proposal Signed is a strong starting point

A signature is a durable business event. It generally represents a clear decision point and gives you a natural reason to send an immediate, relevant message. It is also safer than triggering on a proposal open, where a prospect may open the proposal more than once and where the event does not necessarily indicate intent to buy.

For a client-facing confirmation, use the proposal signer’s email only when the Better Proposals trigger sample contains it. Better Proposals’ API proposal records include fields such as ID, QuoteID, SubjectLine, CompanyName, DateCreated, DateSent, Signed, SignedFirstName, SignedSurname, and SignedEmail. The exact fields available in your Zap can vary by event and account data, so test using a real signed proposal before turning the workflow on.

Better Proposals does not send a native outbound webhook

This distinction is important: Better Proposals’ documented connection method for Zapier uses a Better Proposals API key, and the Better Proposals trigger is listed by Zapier as polling. In other words, Better Proposals is not posting a custom JSON webhook directly to your Volanea endpoint in this setup.

Zapier periodically checks Better Proposals for records that match the event you selected. On Zapier’s Free plan, listed Better Proposals triggers are polled every 15 minutes. Paid Zapier plans may offer different polling intervals, but you should not design a time-critical workflow on the assumption that Better Proposals will invoke Volanea instantly.

That means there is no direct “paste the Volanea endpoint into Better Proposals” setup to configure. The middleware route is:

Better Proposals API → Zapier trigger → Zapier action → Volanea API

This is preferable to inventing a direct webhook integration that does not exist. It also gives you a place to filter events, transform fields, protect credentials, and add idempotency handling before an email is sent.

The Better Proposals proposal data you should map

Because Zapier is polling the Better Proposals API rather than relaying a native webhook request, the input is a proposal record exposed by the Zap trigger, not a Better Proposals webhook body.

A Better Proposals proposal record can contain data shaped like this, using the field names documented in its API examples:

{
  "ID": "219014",
  "QuoteID": "222657",
  "SubjectLine": "Proposal from Testing Company",
  "CompanyName": "Testing Company",
  "DateCreated": "2022-06-13 07:40:08",
  "OriginalDateSent": "2022-06-13 11:02:30",
  "DateSent": "2022-06-13 11:02:30",
  "Signed": "1",
  "SignedFirstName": "Ada",
  "SignedSurname": "Lovelace",
  "SignedEmail": "ada@example.com",
  "SignedDate": "2022-06-14",
  "SignedTime": "09:42:00",
  "Amount": "2500.00",
  "CurrencyCode": "USD",
  "Paid": "0"
}

Treat that as a field model, not as a promise that every field will appear for every proposal. For example, a signed proposal can have signer fields, while a merely created proposal may not. A payment-related field can be empty when no payment was taken through Better Proposals. A sender-related field may also depend on your Better Proposals setup and the event Zapier exposes.

For the signed-confirmation email, map fields deliberately:

Do not blindly map every field into the email. Proposal metadata can be internal, incomplete, or irrelevant to a signer. A short confirmation message with a clear next step is more useful than an email that mirrors the entire proposal record.

Set up the Better Proposals connection in Zapier

Create a Zap and choose Better Proposals as the trigger app. Select Proposal Signed as the event, then connect your Better Proposals account.

Better Proposals’ help documentation says to find the Better Proposals Zapier API key at Settings → Integrations → Zapier. That key authenticates Zapier to Better Proposals. It is not the Volanea key, and it should not be reused for any other service.

After connecting Better Proposals:

1. Select a recent signed proposal as the trigger test record.
2. Inspect the fields Zapier makes available, especially ID, QuoteID, SignedEmail, SignedFirstName, SignedSurname, SubjectLine, and CompanyName.
3. Add a Zapier filter so the workflow proceeds only when SignedEmail exists.
4. If a client-facing email is not appropriate for every signed proposal, add another filter based on document type, company, amount, owner, or a convention in the proposal subject.

Test with a realistic proposal

Do not test only with placeholder data. Create and sign a realistic internal test proposal using an inbox you control. That lets you confirm that signer fields are populated in your account, that the right proposal reference appears in the email, and that the automation does not overlap confusingly with Better Proposals’ own notifications.

It also lets you assess timing. Since the Better Proposals trigger is polling, record the time of signature and the time Zapier begins the run. That gives your team an actual expectation for when a follow-up will arrive.

Keep the Volanea API key out of Better Proposals

The Volanea secret key does not belong in Better Proposals. Better Proposals does not have a native Volanea credential field because this is not a direct Better Proposals-to-Volanea integration.

Instead, store the Volanea secret in the Zapier side of the workflow, ideally in an authenticated API connection or another Zapier-managed secret mechanism. Zapier’s current Code guidance specifically warns against storing secrets in code; for authenticated calls to an API without a native Zapier app, use an API by Zapier connection so credentials are stored and injected by Zapier rather than embedded in code, task history, or logs.

This protects the key from several avoidable failures:

• A key pasted into client-side JavaScript can be extracted by any browser user.
• A key embedded in a public webhook URL can leak through logs, screenshots, browser history, and referrer data.
• A key placed in a Zap code block can be accidentally copied into another Zap or exposed to editors who should not have sending privileges.
• A broad key shared between workflows makes revocation harder after a staff or vendor change.

Use a Volanea secret key such as an sk_… or sk_test_… key only in server-side or managed-credential contexts. Start with a test key where available, then create a production key with the narrowest permissions your operational model supports.

For Volanea setup details, including the current API reference and sender-domain requirements, use the email API setup documentation.

Build the Volanea send request

Volanea’s single-message REST endpoint is POST https://api.volanea.com/v1/send. It uses a Bearer secret key, accepts JSON, and supports an Idempotency-Key request header for duplicate-safe retries.

The body below is designed for the Proposal Signed trigger. It turns Better Proposals signer and proposal fields into a transactional confirmation email.

In Zapier, provide the Better Proposals fields to a code or request step as input values. The illustrative input names below intentionally mirror the Better Proposals field names so the mapping remains easy to audit.

// Zapier Code or server-side middleware example.
// Map these Input Data values from the Better Proposals → Proposal Signed trigger:
// ID, QuoteID, SignedEmail, SignedFirstName, SignedSurname,
// SubjectLine, CompanyName, SignedDate, SignedTime.
//
// Keep VOLANEA_API_KEY in a Zapier-managed API connection or server secret.
// Do not paste the secret into this code block.

const proposal = {
  id: inputData.ID,
  quoteId: inputData.QuoteID,
  signedEmail: inputData.SignedEmail,
  signedFirstName: inputData.SignedFirstName,
  signedSurname: inputData.SignedSurname,
  subjectLine: inputData.SubjectLine,
  companyName: inputData.CompanyName,
  signedDate: inputData.SignedDate,
  signedTime: inputData.SignedTime
};

if (!proposal.signedEmail) {
  throw new Error("Proposal Signed event has no SignedEmail; refusing to send.");
}

const proposalReference = proposal.quoteId || proposal.id;
if (!proposalReference) {
  throw new Error("Proposal Signed event has no ID or QuoteID; cannot create an idempotency key.");
}

const signerName = [proposal.signedFirstName, proposal.signedSurname]
  .filter(Boolean)
  .join(" ");
const greeting = proposal.signedFirstName ? `Hi ${proposal.signedFirstName},` : "Hello,";
const proposalName = proposal.subjectLine || "your proposal";
const companyName = proposal.companyName || "our team";
const signedAt = [proposal.signedDate, proposal.signedTime].filter(Boolean).join(" ");

const emailPayload = {
  from: {
    email: "proposals@your-verified-domain.example",
    name: companyName
  },
  to: [
    {
      email: proposal.signedEmail,
      ...(signerName ? { name: signerName } : {})
    }
  ],
  subject: `We received your signed proposal: ${proposalName}`,
  html: `
    <p>${greeting}</p>
    <p>Thanks for signing <strong>${proposalName}</strong>.</p>
    <p>Our team has received your signed proposal and will follow up with the next steps.</p>
    <p><strong>Proposal reference:</strong> ${proposalReference}</p>
    ${signedAt ? `<p><strong>Signed:</strong> ${signedAt}</p>` : ""}
    <p>Regards,<br>${companyName}</p>
  `,
  text: `${greeting}\n\nThanks for signing ${proposalName}.\n\nOur team has received your signed proposal and will follow up with the next steps.\n\nProposal reference: ${proposalReference}${signedAt ? `\nSigned: ${signedAt}` : ""}\n\nRegards,\n${companyName}`
};

const response = await fetch("https://api.volanea.com/v1/send", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
    "Content-Type": "application/json",
    "Idempotency-Key": `better-proposals:signed:${proposalReference}`
  },
  body: JSON.stringify(emailPayload)
});

const responseBody = await response.json();

if (!response.ok) {
  throw new Error(`Volanea send failed (${response.status}): ${JSON.stringify(responseBody)}`);
}

return {
  proposal_reference: proposalReference,
  recipient: proposal.signedEmail,
  volanea_response: responseBody
};

Important implementation note about the code

The process.env.VOLANEA_API_KEY reference is correct for server-side middleware, but Zapier Code steps should not be used as a place to paste an API secret. If you implement the send entirely in Zapier, configure the Volanea authentication in a Zapier-managed API connection and use the connection in the request step. If you run your own middleware, place VOLANEA_API_KEY in that platform’s encrypted environment-variable or secret manager.

The request itself remains the same: Bearer authentication, JSON content, POST /v1/send, and a stable Idempotency-Key derived from the Better Proposals proposal identifier.

Configure sender identity before production

The from.email value must use an address on a sending domain that has been verified in Volanea. Do not use an arbitrary address from the Better Proposals record as the sender. That can break domain alignment, confuse recipients, and create deliverability problems.

Use a stable sender identity such as:

proposals@yourdomain.example
client-success@yourdomain.example
contracts@yourdomain.example

A proposal lifecycle message is transactional mail. Keep its sender consistent, make the purpose obvious, and give replies a destination that your team monitors. If replies should go to a particular account manager, handle that intentionally through your workflow design rather than dynamically allowing unvalidated proposal data to control the sender.

Before enabling the Zap, verify that:

• The sender domain is verified in Volanea.
• Your from address is permitted by that domain configuration.
• SPF and DKIM records are published as directed in your Volanea domain setup.
• The first production test goes to an inbox your team controls.
• Your plain-text version is readable without HTML.

Add filters and guardrails before sending

A signed proposal does not automatically mean every signer should receive the same email. Build simple protections into the Zap before the Volanea request.

Require a usable recipient

At minimum, add a filter that allows the run only if SignedEmail exists. If Zapier offers an email-format test in your chosen step, use it. A non-empty string is not necessarily a valid deliverable address.

If your business process supports proposals with multiple signers, decide whether the Better Proposals trigger represents the document becoming fully signed or one signature event. Do not assume that a single SignedEmail field represents all parties. Test this with the signature configuration you actually use.

Avoid promotional content in a transactional trigger

A proposal signature is a contextual operational event. The follow-up should acknowledge the signature, state the next step, and provide useful information. It should not silently enroll the signer in a marketing sequence or add campaign content that they did not expect.

If you want to update marketing audiences after a proposal event, make that a separate workflow with its own consent rules, suppression logic, and audience criteria.

Escape untrusted values in custom HTML

The example uses proposal fields in HTML for readability. In a production middleware, HTML-escape dynamic values before interpolating them into a message. Proposal titles, company names, and custom fields can contain characters that change HTML rendering. In a no-code workflow, keep the HTML template simple and avoid inserting arbitrary rich text from a proposal.

When this breaks

A good automation assumes that some hop will eventually fail. This integration has three independent boundaries: Better Proposals data retrieval, Zapier workflow execution, and Volanea email dispatch. Design for the failure mode you actually have rather than retrying blindly.

Better Proposals polling causes a delayed or repeated event

The Better Proposals trigger is polling-based. A signed proposal can therefore be detected after a delay rather than at the exact instant the signer completes the document. If a run is retried, replayed, or manually tested, the same proposal can also reach the Volanea request more than once.

The fix is the idempotency key:

better-proposals:signed:<QuoteID-or-ID>

Use the same key for every retry of the same business event. Do not include the current time, Zap run ID, or a random UUID in that key. Those values create a new key on each retry and defeat duplicate protection.

If your operation can legitimately require more than one different email per proposal, make the key specific to the message type:

better-proposals:signed:<proposal-id>:signer-confirmation
better-proposals:signed:<proposal-id>:internal-handoff

The webhook or code step times out

Although Better Proposals is not directly calling your endpoint here, Zapier steps and any middleware you operate can time out. A timeout creates ambiguity: the email provider may have received the request even though the automation did not receive a response.

That is exactly why the idempotency key matters. Retry with the same key. Volanea can recognize the same send operation instead of creating a second email because the caller was uncertain about the first request.

Keep the send operation short. Do not generate PDFs, call several unrelated CRMs, or wait for manual approval inside the same synchronous request path. If your follow-up requires many operations, queue them in your own backend and return quickly from the webhook receiver.

Fields are absent for some proposals or plans

Better Proposals proposal data is not guaranteed to be uniformly complete. Signer fields are relevant to signed proposals; payment fields may not exist or be populated for unpaid proposals; and certain API or automation capabilities require Better Proposals Premium or Enterprise access.

Avoid sending an email with a blank recipient, a malformed greeting, or an undefined proposal reference. Use explicit checks:

• Stop if SignedEmail is blank.
• Prefer QuoteID, but fall back to ID for the idempotency key.
• Fall back from SignedFirstName to a neutral greeting.
• Omit a timestamp if SignedDate or SignedTime is missing.
• Omit payment amount and currency unless both are present and relevant.

Log the proposal ID and the missing-field reason somewhere your team can inspect. Do not log the Volanea API key, full authorization header, or unnecessary personal data.

The Volanea request returns a 4xx error

A 4xx response usually means the request should be corrected, not repeatedly retried. Common causes include a missing recipient, an invalid sender identity, malformed JSON, an unauthorized key, or a request body that does not match the endpoint schema.

Check the Volanea response body in the Zap task history or your middleware logs. Then correct the sender, credentials, or mapping and test with a new internal test proposal. If you replay an old run after correcting the request, remember that the same idempotency key refers to the original send operation; use a deliberate new message type or test proposal when appropriate.

The email is accepted but not delivered

An accepted API request is not the same thing as an inbox placement guarantee. Delivery can still be affected by recipient-domain policy, an address that no longer exists, suppression status, spam filtering, or sender-domain authentication.

Start your investigation in this order:

1. Confirm the Better Proposals event and proposal data were correct.
2. Confirm Zapier completed the Volanea request successfully.
3. Check Volanea’s message and delivery-event records.
4. Verify the recipient address and whether it is suppressed or bounced.
5. Verify sender-domain authentication and the exact From address.

For a quick pre-send check on addresses collected outside Better Proposals, use the email address verification tool. It is useful for form or CRM data, but it does not replace handling bounces and suppressions after a send.

Production checklist

Before you turn on the workflow for real clients, verify each item below.

• Better Proposals is connected to Zapier using its dedicated Zapier API key.
• The Zap trigger is Proposal Signed, not merely New Proposal, unless your use case requires another event.
• A realistic test proposal has been signed and used as the trigger sample.
• SignedEmail is present and validated before the send step.
• QuoteID or ID is available for the idempotency key.
• The Volanea key is stored in Zapier-managed credentials or a server-side secret store.
• The Volanea key is not in Better Proposals, browser code, a public URL, or a copied code block.
• The From address belongs to a verified Volanea sender domain.
• The message includes both HTML and plain-text content.
• The Zap includes a filter for missing recipient data.
• The idempotency key is stable across retries.
• The team knows where to check Zapier task history and Volanea email events.

Conclusion

The dependable way to send email from Better Proposals with Volanea is a Zapier-mediated workflow, not a native Better Proposals plugin or a direct outbound webhook. Use Better Proposals’ Proposal Signed trigger, inspect the actual fields returned in your Zap, map only the proposal data you need, and make the Volanea POST /v1/send request with a stable idempotency key.

Keep credentials in the systems designed to hold them: the Better Proposals Zapier key stays in the Better Proposals connection, while the Volanea secret stays in a Zapier-managed API connection or server-side secret store. That separation makes the workflow safer, easier to audit, and easier to recover when an automation run is retried.

FAQ

Does Better Proposals have a native Volanea integration?

No. Better Proposals does not provide a native Volanea marketplace app or plugin. Use Zapier as the integration layer between Better Proposals proposal triggers and the Volanea REST API.

Can I call Volanea directly from Better Proposals?

Not through a documented native outbound-webhook setting. Better Proposals supports API and Zapier-based automation on qualifying plans, so the practical route is Better Proposals → Zapier → Volanea.

Which Better Proposals trigger should I use for a confirmation email?

Use Proposal Signed when the email confirms signature completion or starts onboarding. Use Proposal Paid for payment-related operational follow-up, and use Proposal Opened primarily for internal sales alerts rather than client-facing messages.

Why do I need an Idempotency-Key for this workflow?

Polling, retries, timeouts, manual replays, and temporary network failures can cause the same proposal event to be processed more than once. An idempotency key based on QuoteID or ID helps ensure the same transactional email is not sent twice.

Where should I store the Volanea API key?

Store it in a Zapier-managed API connection or in your middleware platform’s encrypted secret manager. Do not put it in Better Proposals settings, client-visible JavaScript, public URLs, or a copied Zap code block.