Manually copying website enquiries and orders into a CRM can lead to delays, mistakes and missing information. An integration can automate that transfer, but connecting two applications involves more than installing a plugin. You need to decide which data moves between them, who can access it and what happens when delivery fails.
This guide covers the foundations of website automation you can monitor and maintain, whatever platform your business uses.
1. APIs and webhooks: what is the difference?
An API is an interface that lets one application request information or ask another application to perform an action, following documented rules. Your website might send form details to the CRM API and request a new sales opportunity. The CRM then returns the outcome or an error.
A webhook is an automatic notification sent to a configured address when an event happens. After an order is recorded, for example, your shop sends a message to the application handling the integration. That application checks the message and updates the CRM.
The practical difference is who starts the exchange: with an API, your application requests an action; with a webhook, another application tells you something has happened. Webhooks commonly use HTTP requests, as many APIs do, so these are complementary approaches rather than competing technologies.
- API only: the integration periodically checks for new enquiries and transfers them.
- Webhook plus API: it receives an order notification, then uses the CRM API to create the relevant record.
- Combined with periodic checks: notifications trigger transfers, while a separate reconciliation process looks for missed events.
A webhook does not guarantee immediate processing. Notifications can arrive late, arrive more than once or fail to arrive, so the integration needs to account for these situations.
2. Define the workflow and data before implementation
Start with a clear business rule: a valid form submission creates a sales opportunity and links it to a contact, for example. For orders, decide whether the transfer starts when an order is placed, payment is confirmed or a particular status changes. These are different events with different meanings.
Map the source fields to the CRM fields. Check names, data types, required values, currencies and time zones. Handle missing information explicitly rather than filling gaps with made-up values.
- Choose the event that triggers the transfer.
- Define which record should be created or updated in the destination application.
- Choose identifiers that link the enquiry or order to its CRM record.
- Identify the information the workflow actually needs and exclude unnecessary data.
- Assign responsibility for reviewing errors and restarting failed operations.
Read both applications’ documentation, including authentication requirements, usage limits, API versions and webhook retry policies. For WordPress sites, check that your integration plugin supports the versions you use. You can assess WordPress hosting against your project’s technical requirements, but hosting does not replace integration configuration.
3. Protect access credentials and verify notifications
Access credentials allow the integration to act on your behalf. Keep them on the server in a secrets management system or protected configuration outside publicly accessible files. Never put them in browser-delivered JavaScript, URLs, screenshots or code repositories.
Grant only the permissions the workflow needs. An integration that creates opportunities should not automatically receive permission to delete every contact. Use separate credentials for testing and production, restrict team access and replace secrets if you suspect exposure. If the application uses OAuth, protect refresh tokens as well.
A hard-to-guess address is not enough
For webhooks, use the sender’s documented verification method. This may involve a cryptographic signature generated with a shared secret. Verify that signature against the original request body before transforming it. Where the protocol includes a timestamp, check the permitted time window too, helping limit replay of captured messages.
Use HTTPS with a valid certificate and validate the structure of incoming data. Treat the content as untrusted until verification is complete. An IP allowlist can provide an additional safeguard where the provider supports it, but it does not replace message authentication.
4. Plan for failed deliveries
A CRM may respond slowly, impose request limits or become temporarily unreachable. Separate saving the website enquiry from sending it to the CRM: store the data and a dispatch task durably, then process the transfer separately. This avoids making the form confirmation depend entirely on an immediate response from an external application.
When receiving a webhook, acknowledge success only after the validated message has been durably stored or processed as the protocol requires. If you acknowledge it first and the process stops afterwards, the event may be lost.
- Temporary errors: retry with progressively longer delays and a small random variation.
- Rate limits: follow the API’s instructions, including the Retry-After header when supplied.
- Invalid data: correct the underlying problem before retrying; repeating the same request will not fix it.
- Access denied: check credential validity and permissions.
Set a retry limit and retain unsuccessful operations in a review queue. Log the event identifier, status and error category without recording access credentials or unnecessary personal data. Alerts should highlight operations that need someone’s attention.
If the integration needs separate background processes and configurable resources, you can evaluate cloud hosting. Check the specific requirements for message queues, scheduled tasks and outbound connections rather than assuming they are available in every environment.
5. Prevent duplicates and out-of-order updates
A missing response does not necessarily mean an operation failed. The CRM may create a contact, while your integration encounters a connection error before receiving confirmation. Retrying without safeguards could create another record.
The key principle is idempotency: repeating the same operation should have the same business effect as performing it once. If the API supports an idempotency key, reuse that key for every retry of the same operation, following its documented rules and retention period.
Also maintain a local record of processed events, using unique identifiers and atomic operations that prevent two workers from handling the same event simultaneously. Simply checking whether a record exists and then inserting it can still allow duplicates when requests arrive together.
Keep event identifiers separate from customer and order identifiers. Do not automatically treat an email address as a universal unique identifier. For updates, check event versions or ordering so that an older notification cannot overwrite a newer status.
6. Test the complete workflow and establish regular checks
Before launch, use a test environment where available and work with fictional data. Test failure scenarios as well as successful transfers.
- Send the same event twice and check the outcome.
- Simulate a delayed response, expired access and missing required fields.
- Test notifications arriving in reverse order and the replay of failed operations.
- Periodically compare source enquiries and orders with the corresponding CRM records.
The practical takeaway: begin with a narrow workflow, stable identifiers and clear error-handling rules. Document permissions, retries and responsibilities, then expand the automation after reviewing the results. To discuss your project’s hosting requirements, use the GazduireOnline.ro contact page; integration configuration and ongoing maintenance should be planned separately.
