Integrate the systems, automate the work.

• Start with CRM and ERP integration when systems disagree about a customer.

  When sales, finance and the website each hold a different version of the same record, fixing the data flow comes before automating anything that reads it.

• Start with workflow automation when a process waits on someone remembering.

  When the data already moves between systems but approvals, handoffs and reminders still depend on a person, the rules are what need encoding.

• Choose an API or webhook integration when no ready-made connector exists.

  Where a platform offers an API or webhooks but no built-in connection to the other system, a custom integration carries the data, with its failures handled.

• Look to web apps and SaaS when no existing system can hold the process.

  When a process needs its own records, screens and permissions, connecting tools that do not fit it only moves the problem, and an application is the honest answer.

• Look to AI solutions when a step needs language or judgment, not a rule.

  Integrations and workflows are the foundation AI features run on, but reading documents, answering questions or drafting replies is AI work, covered under AI solutions.

A website should treat a payment as successful only when the payment provider reports it through a verified event received on the server, not when the customer reaches a thank-you page. The integration then updates the order, invoice or access record once, even if the same event arrives again, and records any failure for review.

Fulfillment cannot rely on the checkout landing page alone, because a customer can pay successfully and lose their connection before that page loads, and fulfillment can be triggered more than once for the same checkout session. The order is therefore updated from the provider event, and processing checks whether that payment was already handled.

Providers retry events they could not deliver, which is why an endpoint has to cope with repeats and delays. Some payment providers keep retrying a failed delivery for up to three days, and some do not guarantee that events arrive in the order they were generated, so an endpoint cannot assume either the timing or the sequence.

Building the checkout itself, including keeping card data off your servers, is covered under e-commerce websites, and turning billing events into plan access is part of multi-tenant SaaS development. Refunds and disputes are handled by the business with its payment provider; the integration records those events and routes them to the right people.

Sending messages automatically takes an account with each provider in the name of the business, permission from recipients where the channel requires it, message formats the provider accepts, and a record of the delivery status of every message. The integration sends when a rule fires, honors opt-outs and alerts someone when a message fails.

WhatsApp adds rules of its own. The WhatsApp Business Platform requires businesses to obtain opt-in permission before messaging people, opens a 24-hour customer service window when a customer messages or calls the business, and allows only pre-approved message templates outside that window. Setting up the account and its templates can be part of the work, and the platform decides whether each template is approved.

Email alerts and confirmations are sent through the API of an email provider or over SMTP, and depend on an authenticated sending domain. Everyone sending to Gmail accounts has to set up SPF or DKIM, and senders of more than 5,000 messages a day to Gmail accounts also have to set up DMARC and support one-click unsubscribe on marketing messages. Meeting those requirements still does not guarantee that messages pass Gmail spam filters, so delivery status is recorded rather than assumed.

Google Workspace connections typically create calendar events from bookings, collect Google Forms responses, write rows to Google Sheets, store files in Google Drive or read a shared mailbox in Gmail, using access the business grants. Social media connections retrieve leads from advertising lead forms into the CRM and publish scheduled posts, within the access each platform approves.

Google controls how much access an application gets. An application requesting sensitive scopes has to be reviewed by Google before any Google Account can grant that access, with exceptions such as internal-only Workspace apps, and domain-wide delegation, which lets an application reach the data of users across a Workspace domain, has to be set up by a super administrator of that domain. Access is always requested in the name of the business, never through personal passwords.

Social platforms gate their APIs behind approval of their own. An app used by anyone without a role on it may have to undergo a review by the platform first, and access to lead data can be a separate program that a business applies to. Retrieving leads and publishing posts are built within the access each platform grants, and the platform decides that access.

Webhooks are received safely by verifying that each request came from the sender, acknowledging it quickly and doing the real work afterwards from a queue. Receiving them reliably means expecting the same event twice, events out of order and failed deliveries that the sender retries, and designing the endpoint so none of those changes the result.

Senders set these expectations themselves. Some count a delivery as failed when the server does not respond within a set time, and an endpoint might receive the same event more than once, which it can guard against by logging the IDs of events it has already processed.

Checking the timestamp of each delivery against a tolerance helps prevent replay attacks, and the webhook ID can serve as an idempotency key. A queue between the endpoint and the work acts as a buffer that smooths intermittent heavy loads, which stops a slow downstream system from turning into failed deliveries.

• Verify the signature on every request before trusting its content.
• Reject requests whose timestamp is too old to be a fresh delivery.
• Return a success response quickly, before any slow processing.
• Place the event in a queue and process it separately.
• Record each event ID, so a repeated delivery is recognized.
• Handle events that arrive in any order.
• Hold events that cannot be processed, and alert someone.
• Fetch the current record when an event only signals that something changed.

A third-party API is connected securely by keeping its keys and tokens on the server, never in browser code, granting the integration only the permissions it needs, validating every response before using it, and slowing down when the provider signals a rate limit instead of retrying until the account is blocked.

The OAuth 2.0 framework lets an application obtain limited access to another service without handling the password of the account owner, and the privileges of each access token should be restricted to the minimum required for the use case.

Unsafe consumption of third-party APIs is a recognized API security risk, because developers tend to trust data from third-party APIs more than user input. Responses are therefore validated like any other input, connections use TLS, and redirects from the other API are not followed blindly.

Rate limits are part of the contract. A provider that limits requests can answer with HTTP status 429 Too Many Requests and a Retry-After header saying how long to wait, and the integration honors it.

Other systems are sometimes slow, so every call has a timeout and none is allowed to hold a page or a workflow open. Work that does not need to finish while a visitor waits, such as passing an inquiry to a CRM, runs in the background after the page has responded, and data that rarely changes is cached for a set period instead of being requested every time. Where a provider maintains an SDK for the language the integration is written in, the integration can use it instead of hand-written requests. Designing and documenting an API that other systems build on is API development, covered under web apps and SaaS.

Lead automation starts once the website has stored an inquiry: it matches or creates the contact in the CRM, assigns an owner by rules the business sets, alerts that person, acknowledges the sender and schedules the follow-up, then escalates anything left unanswered. The rules differ for every business, so they are written down before being built.

Marketing automation continues from the same records: segments built from what a contact asked about, follow-up sequences that stop when someone replies, and campaign triggers such as a download or a booking. Each sequence checks the consent status recorded on the contact before it sends anything.

The last step is what makes measurement possible. The CRM records whether an inquiry became a qualified lead, against the source captured when it was submitted, and reconciling that with website analytics is covered under analytics implementation.

The steps below are one example; the rules, owners and timings differ for every business.

• The website has validated and stored the inquiry.
• The CRM matches an existing contact or creates a new one.
• A routing rule assigns an owner by service, region or source.
• The owner is alerted and the sender receives an acknowledgment.
• A follow-up task is scheduled with a due date.
• An inquiry still unanswered at the due date escalates to a second person.
• The outcome is recorded in the CRM against the original source.

Notifications stay useful when each one goes to a named person who can act on it, through the channel that person actually watches, and when repeated events are grouped instead of sent one by one. Alerts that nobody acknowledges escalate to a second person, and anything that fires constantly is reviewed rather than ignored.

Notifications here cover business events, such as a new booking, a failed payment or an approval waiting too long. Monitoring whether a website or server is up is engineered under performance and security and operated under hosting, maintenance and support.

No notification is instant by guarantee. Providers, carriers and mailboxes add delays of their own, so time-critical alerts use more than one channel and record whether they were delivered.

• A named recipient or role for every notification, never an address nobody owns.
• A channel chosen by urgency: email or a dashboard for records, SMS or WhatsApp for time-sensitive events.
• Grouping, so a run of similar events arrives as one summary.
• Throttling, so a failing system cannot send hundreds of messages.
• Escalation when an alert is not acknowledged.
• Quiet hours for anything that can wait.

An integration connects systems that each hold part of a customer, an order or a task, where each system offers an API, webhooks or a supported connector.

• Every connection starts from an inventory of the systems involved, what each API or connector exposes and the plan limits that apply, confirmed before the work is scoped.
• Each shared field has one system of record, and sync direction, matching keys and conflict rules are written down before anything is built.
• API keys and tokens stay on the server, never in browser code, and each integration and each access token holds only the minimum permissions it needs.
• Incoming webhooks are verified, acknowledged quickly and processed so that a repeated delivery changes nothing twice.
• Only temporary failures are retried, with increasing waits, and work that still fails is held for review and alerted rather than dropped.
• Accounts and credentials can sit with the business or be operated by us on its behalf, and either way they are documented and access is reviewed.
• Consent, marketing permission and which personal data may move between systems are decisions the business makes with its legal adviser, and the build implements them.