Connect Your Apps to Convertly Without Losing the Lead
Choose the right Convertly connection for website forms, external apps, and server-side intake, then test ownership, source context, and the resulting lead.
Your enquiries do not all arrive from one place. A website, property portal, chat tool, or another business application may hold the first useful customer request. The challenge is bringing that request into the same sales workflow without repeated copying.
Convertly offers several ways to receive leads. The right choice depends on what the source application can send and the result you need in the CRM.
Choose the simplest supported connection
Start in Integrations to see the available connections. If a dedicated integration fits your source, review its guided setup first.
For other sources, the main choices are:
- Native forms: embed a Convertly form on your website.
- Universal Webhook Mapper: receive compatible events from an application that can send webhooks.
- Inbound Leads API: let a trusted server send lead data in Convertly’s supported format.
- CSV import: bring in an existing list as a deliberate bulk operation.
These options solve different problems. An import can help with a starting list; it does not keep another application continuously synchronized.
Use Universal Webhook Mapper for compatible senders
Universal Webhook Mapper, or UWM, translates a supported incoming event into useful lead information. Your sales team does not need to understand the technical format to benefit from the connection, but the person setting it up should verify the sender’s compatibility.
An Admin selects an available recipe or generic connection, gives the source a recognizable name, and reviews a representative sample. The setup determines which incoming values become contact details, source information, and other supported fields.
The result to aim for is simple: a new enquiry arrives with the information the team needs to respond. UWM is inbound intake, not universal two-way synchronization with every application.
Use the API when you control the sending server
The Inbound Leads API suits a trusted server that can prepare the supported lead data directly. An Admin creates a source-specific key and the developer keeps it on the server.
Do not put the key into public browser code or a website form. Native form embeds provide a different intake path for that use case.
The documented API is for lead intake, not a general-purpose API for reading every CRM module. Review the supported fields before designing a broader integration around it.
Test the sales result, not only the connection
Send a controlled test enquiry and check the actual lead:
- Are the name and contact method correct?
- Is the expected source retained?
- Is the owner or routing behavior appropriate?
- Did available campaign context arrive?
- Did a repeated event produce the intended duplicate or update behavior?
Defaults can fill supported missing fields, while incoming mapped values may take priority. Review alert recipients separately from ownership so the team knows who is responsible.
Keep one person responsible for connection health
Use the integration’s logs when an enquiry is missing or unexpected. A sender changing its fields or authentication can affect the connection even when the sales process has not changed.
Keep source URLs, keys, and authentication secrets private. Share safe timestamps and visible error details with support instead of raw customer records.
Explore the integration catalog, Universal Webhook Mapper, and Inbound Leads API. Begin with one source, verify the handover, and expand from a connection your team can trust.