Proposals from your CRM with Zapier, Make or n8n

Beta. If you don't see Settings → Integrations in your Proposals account yet, write to support@proposals.co and we'll switch it on for your team.

A common setup: a deal in your CRM moves to "Proposal", the automation sends the deal's notes to Proposals, and when the draft is ready the deal owner gets a message with a link to review it. The owner checks it and publishes it in the panel. If you trust the flow, the automation can publish too, as long as the key has the publish permission and nothing blocks publishing.

There is no dedicated Zapier or Make app yet. You use the REST API through the tools' generic HTTP step (Webhooks by Zapier, Make's HTTP module, n8n's HTTP Request node).

1. Create an API key

A Proposals admin goes to Settings → Integrations → API keys and creates a key:

• Name: something you'll recognise later, for example Zapier – CRM.
• Permissions: keep the defaults (read brands, read proposals, create and change). Add publish only if the automation should publish without a person.
• Copy the secret (prp_live_…). It is shown once.

Store it in the tool's secret storage: a Zapier or Make connection field, or an n8n credential of type Header Auth with the name Authorization and the value Bearer prp_live_….

2. Find your brand ID (if you have more than one brand)

curl https://api.proposals.co/api/public/v1/brands \
  -H "Authorization: Bearer $PROPOSALS_API_KEY"

Note the id of the brand the proposals should be sent from. With one brand you can skip brand_id.

3. Create the proposal

HTTP step settings:

• Method: POST
• URL: https://api.proposals.co/api/public/v1/proposals
• Headers:
  • Authorization: Bearer prp_live_…
  • Content-Type: application/json
  • Idempotency-Key: deal-{{deal_id}}-create
• Body (JSON):

{
  "client": {
    "name": "{{company_name}}",
    "website": "{{company_website}}",
    "contact": { "name": "{{contact_name}}", "email": "{{contact_email}}" }
  },
  "context": "{{deal_notes}}",
  "brand_id": 42,
  "language": "en",
  "pricing": {
    "amount": {{deal_amount}},
    "currency": "USD",
    "tax_basis": "net",
    "billing": "one_off"
  },
  "external_reference": "{{deal_id}}"
}

Map the {{…}} placeholders to your CRM fields. If the deal has no agreed amount yet, send "amount": null: the proposal then says the price is to be agreed, and never shows a guessed number.

Use the deal ID in both Idempotency-Key and external_reference. If the step is retried, or the same deal triggers twice, you still get one proposal: a retry returns the first response, and a second proposal for the same deal is refused with 409 external_reference_exists (the existing proposal's ID is in detail.params.proposal_id).

The response is 202 with the proposal in status generating. Save its id.

4. Wait for the draft

Writing takes 30 to 120 seconds. Choose what your tool handles best:

• Zapier: add Delay by Zapier for 2 minutes, then a GET step to https://api.proposals.co/api/public/v1/proposals/{{id}}. If the status is still generating, add a second delay and check again.
• Make: use a Repeater with a Sleep module (30 seconds) and an HTTP GET, and stop when the status is no longer generating.
• n8n: a Wait node plus an IF node on status that loops back while it's generating. The response's next_poll_after_ms tells you how long to wait.

Alternatively, create the proposal with ?wait_seconds=50 in the URL. The call then waits up to 50 seconds and often returns the finished status directly. It may still say generating, so keep one delayed check as a fallback.

5. Act on the status

Add a filter or router on status:

panel_url requires logging in to Proposals, so it's safe to post in an internal channel. Don't send it to the client.

6. Optional: publish from the automation

Only with a key that has the publish permission:

curl -X POST https://api.proposals.co/api/public/v1/proposals/$PROPOSAL_ID/publish \
  -H "Authorization: Bearer $PROPOSALS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: deal-$DEAL_ID-publish" \
  -d '{"confirm": true}'

The response contains public_url, the link for the client. If the pre-publish check finds a blocker, you get 422 preflight_blockers and nothing is published; there is no way to force it. Each publish through an integration also sends the proposal owner a notification.

Publishing doesn't send anything to the client. Put public_url in the email your CRM or email tool sends, then tell Proposals it was sent:

curl -X POST https://api.proposals.co/api/public/v1/proposals/$PROPOSAL_ID/mark-sent \
  -H "Authorization: Bearer $PROPOSALS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: deal-$DEAL_ID-mark-sent" \
  -d '{}'

7. Optional: follow the client's reaction

A scheduled step (for example once an hour) can read the proposals of open deals with GET /proposals/{id} and update the CRM from status (opened, accepted) and engagement (first_opened_at, opens, accepted_at). If you only kept the deal ID, find the proposal with GET /proposals?external_reference={{deal_id}}. There are no webhooks yet.

Limits to keep in mind

• 10 new proposals per minute per key and at most 3 being written at the same time per team. If a burst of deals arrives, 429 responses tell you how long to wait in Retry-After; Zapier, Make and n8n can all retry with a delay.
• Every proposal counts against your plan like one made in the panel.

Full list of endpoints and fields: API reference. Status meanings, errors and idempotency: overview.