Integrations and API
Connect what you already use, and drive from the API everything the screen does.
Everything the screen does, the API does: the same operation, the same record, the same trail. Your proposal leaves with delivery reputation and a log of what happened, and comes back carrying signature, evidence and a timestamp. That delivery is Qsendyx and that signature is Qsignyx, two products of the house with an explicit contract between them instead of a shared database.
API tokens
Create a token per integration, in place of one token for everything: a token belongs to a single workspace and can be revoked on its own. The secret appears once, at creation. If it is lost, revoke it and create another. We cannot show it again, because we do not store it in readable form.
Webhooks
Register an endpoint and receive events as they happen: a deal moving stage, a proposal accepted, a signature completed. Deliveries are logged, so you see what was sent and what the receiving side answered.
Lead capture form
A capture key is publishable, which an API token is not. It can sit in your HTML in plain sight, because it grants exactly one capability: creating a lead in your workspace. It reads nothing. Create one key per site or campaign, and revoke each one on its own. Leads arrive with source "website" and no owner, ready for triage.
<form action="https://api.qnexyx.com/api/v1/public/leads/qnx_pub_SUA_CHAVE" method="POST">
<input name="name" required placeholder="Nome">
<input name="email" type="email" placeholder="E-mail">
<input name="phone" placeholder="Telefone">
<input name="company" placeholder="Empresa">
<textarea name="message" placeholder="Como podemos ajudar?"></textarea>
<!-- honeypot: invisível e vazio. Robô preenche, gente não. -->
<input name="website" tabindex="-1" autocomplete="off" aria-hidden="true"
style="position:absolute;left:-9999px">
<!-- atribuição de campanha: preenchidos pelo script a partir da URL da página -->
<input type="hidden" name="utm_source"><input type="hidden" name="utm_medium">
<input type="hidden" name="utm_campaign"><input type="hidden" name="utm_term">
<input type="hidden" name="utm_content">
<script>
var f = document.currentScript.closest('form'),
q = new URLSearchParams(location.search);
['utm_source','utm_medium','utm_campaign','utm_term','utm_content']
.forEach(function (k) { var v = q.get(k); if (v) f.elements[k].value = v; });
</script>
<button type="submit">Enviar</button>
</form>After submit, the visitor lands on the redirect URL you set on the key, or on a plain thank-you page when you set none. The same endpoint accepts JSON for server-side integrations. The same email within 24 hours in the same workspace is a single lead: a double submit never becomes two rows to triage.
Posting from your own server
Your backend can POST the same fields as JSON to the same URL, with content-type application/json. Use it when your form already has its own validation, auto-reply or anti-spam, and you want the funnel on top of what exists. Send the visitor fields only: website is the honeypot, so leave it out.
| Answer | What it means |
|---|---|
| 202 accepted | The lead is handled. The honeypot and the 24-hour dedupe answer this too, so read 202 as "nothing left for you to do", rather than as "a row was written". |
| 200 or 303 | The form-encoded path: the thank-you page, or a redirect to the URL set on the key. A JSON submit answers 202 instead. |
| 404 | Unknown or revoked key. Both answer the same, so a wrong key learns nothing from the answer. |
| 422 | A field is invalid, or the body is not valid JSON. name is the only required field. |
| 429 | Above the limit: 100 leads per key per hour. The embedded form also holds 10 per visitor IP per hour. A JSON submit from your server answers to the key limit alone, because the whole site would share one IP there. |
| 413 or 415 | Body above 32 KB, or a content-type other than JSON and form-encoded. |
Knowing which campaign a lead came from
The snippet above carries the utm_source, utm_medium, utm_campaign, utm_term and utm_content parameters from the page URL into the lead, where they show up next to the visitor message. Two campaigns pointing at the same page stay distinguishable with no extra setup. When campaigns land on different pages, or you want to revoke one source without touching the others, create one key per campaign: each key counts its own leads and dies alone.
Native connectors
Tools that already capture leads for you deliver them straight into your pipeline: paste the key URL with the tool suffix into its webhook field, and every response becomes a lead with the right source. No middleware, no code.
- Typeform: Connect → Webhooks → add …/leads/qnx_pub_SUA_CHAVE/typeform. Answers are mapped by type and label: email, phone, name, company and a long-text message. Hidden utm_* fields on the form carry campaign attribution.
- RD Station: register …/leads/qnx_pub_SUA_CHAVE/rd-station as the webhook URL. Batches are welcome: each lead in the payload becomes one lead here.
- Google Ads Lead Forms: in the lead form webhook integration, use …/leads/qnx_pub_SUA_CHAVE/google-ads. Name, email, phone and company come from the form columns; the campaign id arrives as utm_campaign.
- Meta Lead Ads: connect your Facebook page with one click on the Integrations screen, with no webhook to paste. Each ad lead arrives within seconds, with campaign and ad name attached.
- Zapier / Make (and anything else): POST JSON to the key main URL with name, email, phone, company, message and optional utm_* fields.
curl -X POST https://api.qnexyx.com/api/v1/public/leads/qnx_pub_SUA_CHAVE \
-H "Content-Type: application/json" \
-d '{"name":"Maria Prado","email":"[email protected]",
"utm_source":"newsletter","utm_campaign":"lancamento-agosto"}'Calendar and meetings
Two more connections live on the scheduling page. Each seller connects their own Google Calendar or Microsoft 365, so a busy hour is never offered to a visitor. If your team already books through Cal.com or Calendly, one webhook brings those meetings in: the lead is marked and the sales agent stops following up, exactly as it does for a meeting booked here. Scheduling covers both.
Idempotency
Writes accept an Idempotency-Key header. Repeating a request with the same key returns the same response instead of creating a second record, which is what you want when a connection drops mid-request and your client retries.
curl -X POST https://api.qnexyx.com/api/v1/deals \
-H "Authorization: Bearer $QNEXYX_TOKEN" \
-H "Idempotency-Key: 8f1c1c2a-1f0e-4e2f-9a1b-6d2f5e7c9a10" \
-H "Content-Type: application/json" \
-d '{"title":"Helix Data","amount":"17280.00","currency":"USD"}'