API integration

An API integration connects two pieces of software so they exchange information directly, without someone copying it by hand. In practice, API integration for a business means the website form creates the lead in the CRM, the online store sends each order and customer to the CRM and the accounting system, and the booking tool updates the customer record when an appointment changes. We connect CS+, our CRM, or the CRM you already use, with the other systems you rely on. Canada Create is a Toronto agency with an office at 126 Willowdale Avenue, serving businesses across Canada.

Contents

• What an API integration does for a business
• Systems businesses usually connect
• Deciding the source of truth
• Field mapping in plain language
• One way or two way sync
• Errors, duplicates and alerts
• Credentials, access and logging
• Testing with sample records and documentation
• When a vendor changes its API
• Where integration sits beside your CRM and website
• Privacy, licences and vendor terms
• How we run an integration project
• What API integration costs
• Choosing an integration partner and your next step

What an API integration does for a business

API stands for application programming interface. It is the published doorway a piece of software offers so other software can ask it for information or send it new information. When your online store tells the CRM “a new customer just bought this,” it is using an API. A webhook is the reverse: the store calls out to a waiting address the moment something happens, instead of waiting to be asked.

The problems owners describe

Owners and operations managers rarely ask for “an API.” They describe symptoms:

• Someone on the team copies web form entries into the CRM every morning, and some get missed.
• Sales does not know a customer already has an open support issue or an unpaid invoice.
• The same customer exists three times with three spellings across three systems.
• Invoices are typed into accounting by hand from orders that already exist in the store.
• Nobody is sure which system has the right phone number.

Each of these is a sign that two systems should be talking and are not. An integration removes the double entry, and the hours it frees can be tracked by the client against the time the team used to spend on it.

What integration is not

Integration connects software you already have. Building a new application from scratch is a different job, covered by our custom software development service. Many projects start with an integration and find that is all they needed.

Systems businesses usually connect

Most integrations we discuss with owners involve the CRM at the centre and a handful of other systems around it. We describe them here as categories rather than brands, because the right connection depends on the exact product and plan you hold.

Common connections

• Website forms: contact, quote and booking forms on WordPress or another platform creating a lead with the page it came from.
• Ecommerce: Shopify or WooCommerce orders, customers and abandoned carts flowing to the CRM.
• Accounting: invoices, payments and customer balances moving between the CRM and the accounting system.
• Booking and scheduling tools: appointments created, moved and missed, reflected on the customer record. Our online booking system service builds or customizes the booking side itself.
• Phone system: call logs and missed calls attached to the right contact.
• Email platform: subscribers, consent status and unsubscribes kept in step with the CRM.
• Microsoft 365 or Google calendars and contacts: meetings and contacts shared with the CRM.
• Internal databases and spreadsheets: inventory, price lists or job records the business built itself.

Checking that a connection is possible

Not every product offers an API, and some offer it only on certain plans. Before quoting, we confirm that each system you want connected has an API or webhook your licence includes, and what it allows: some let you read and write customers, others only read orders.

Deciding the source of truth

The most important decision in any integration is not technical. For every piece of information, one system has to be the source of truth: the place where that value is created and corrected, and whose version wins when two systems disagree.

Typical decisions

• Customer contact details: often the CRM, because sales and service update them there.
• Prices and products: usually the store or the inventory system.
• Invoices, payments and balances: the accounting system, always.
• Appointment times: the booking tool.
• Marketing consent: wherever consent is captured, with changes passed everywhere else.

Why it matters

Without this decision, two systems can overwrite each other in a loop, or an old phone number in one system can quietly replace a corrected one in another. Writing the source of truth down, field by field, is the first deliverable in an integration project, and it is written in plain language so the owner can sign off on it.

Field mapping in plain language

Field mapping is the list of what moves where. The store calls it “billing phone,” the CRM calls it “mobile,” and accounting calls it “contact number.” A mapping document says, for each field, which system it comes from, which field it lands in, and what happens if it is empty or in a different format.

What a mapping covers

• Names, emails, phone numbers and addresses, including how provinces and postal codes are formatted.
• Status values that differ between systems, such as “paid,” “settled” and “closed.”
• Dropdown choices that must match exactly in both places.
• Dates and time zones, which matter for a business with customers in several provinces.
• Language preference for English and French communications.
• Fields that should never move, such as internal notes or sensitive details.

The mapping is shared as a simple table in a document, reviewed by the people who use each system, and kept as part of the documentation in your name.

One way or two way sync

A one way sync sends information in a single direction: new orders go from the store to the CRM, and nothing comes back. A two way sync keeps both sides updated: change a phone number in either system and the other follows.

When one way is enough

One way is simpler, cheaper to build and easier to support. It suits most website form connections, order feeds into the CRM and invoice exports into accounting, where one system clearly creates the record and the other only needs a copy.

When two way is worth it

Two way sync suits shared customer records that several teams update, or calendars where an appointment can be moved from either side. It needs clear rules for conflicts: if the same contact is edited in both places within minutes, which change wins? The source of truth decision answers that.

Timing

Some data needs to move the moment it changes, such as a new lead that sales should call. Some can move on a schedule, such as nightly inventory counts. Choosing the right timing for each feed keeps the integration within the request limits vendors set on their APIs.

Errors, duplicates and alerts

Every integration fails sometimes. A vendor’s service is briefly unavailable, a required field arrives empty, or a password expires. A good integration expects this.

Handling failures

• Failed records are retried, and if they still fail, kept in a list rather than lost.
• An alert goes to a named person at your business, by email, with the record and the reason.
• Partial failures do not leave half a record behind, such as an order without its customer.

Duplicates

Duplicates are the most common complaint after a poor integration. The rules for matching need deciding up front: match a customer by email first, then phone, then name and postal code, and decide whether to merge, update or flag for a person to review. Existing duplicates are usually cleaned up before the integration goes live, so the new connection does not multiply the mess.

Credentials, access and logging

An integration needs keys or tokens that let one system act inside another. Those credentials are as sensitive as a password, and they belong to you.

Credentials in your accounts

• API keys and app connections are created in your accounts, under an integration user you own, not under a contractor’s personal login.
• Each connection gets only the access it needs: an order feed that only reads orders should not be able to delete customers.
• Keys are stored securely, never in an email or a shared spreadsheet, and are changed when people with access leave.

Access by role

Inside the CRM, the information that arrives from other systems follows the same access rules as everything else. If only managers should see invoice balances, the integration should not place them where every user can read them.

Logs

A log records what moved, when, and whether it succeeded. When a customer says “I updated my address last week,” the log shows whether the change came through. Logs should hold enough to troubleshoot without storing more personal information than needed. Our cyber security services can review how keys and access are handled across your systems.

Testing with sample records and documentation

Testing before live data

Integrations are tested with sample records first, ideally in a sandbox or test account if the vendor offers one. Tests cover the normal case, the unusual case (a customer with no phone, a French accent in a name, an order with several discounts and a split shipment), and the failure case (the other system is unavailable). Your team checks the results in the systems they know before anything touches real customers.

Going live carefully

Many integrations go live on a small slice first, such as new records only, before historical data is brought across. That limits the damage if something unexpected appears.

Documentation in your name

At handoff you receive written documentation: what connects to what, the source of truth and field mapping, the credentials used and where they live in your accounts, how alerts work, and what to do when something fails. It is kept in your own files, so any qualified developer can understand and support the integration later.

When a vendor changes its API

Software vendors update their APIs. They add fields, retire old versions, change how authentication works or alter the request limits. Usually they announce it in advance; occasionally they do not.

Maintenance planning

• Keep a record of which API versions each connection uses.
• Have someone responsible for reading vendor announcements for the systems you connect.
• Budget for updates when a vendor retires a version.
• Re-test the integration after any major change to either system, including a CRM or store plan change.

Ongoing support for integrations can be included in a monthly arrangement or quoted when changes arise, and the choice is written into your proposal. Sites that also need updates and backups can pair this with our website maintenance and security plans.

Where integration sits beside your CRM and website

An integration is only as useful as the systems it connects. If the CRM itself is not set up well, connecting it to everything moves messy data faster. Our CRM setup and automation services cover the CRM side, whether CS+ or the CRM you already run, and teams settled on a major platform can read about our consulting for an established marketing and sales platform.

Website forms often need work before they can feed a CRM cleanly, which our web development team handles. Stores that need checkout or catalogue changes alongside the connection can look at ecommerce website builds. Once data flows reliably, follow up can be automated, as described on our sales follow up automation page. Adding AI to existing systems is a separate topic, covered by the new page in this batch on AI integration.

Privacy, licences and vendor terms

Integrations move personal information between systems, so privacy rules follow the data. PIPEDA, the federal privacy law, applies in general terms to personal information moving between your systems: collect what you need, use it for the purpose you stated, protect it, and be able to tell people where it is. In Quebec, Law 25 adds its own requirements for personal information. Health and legal information need extra care, and often should not move into marketing systems at all.

Licences and vendor terms

Only systems you are licensed to use should be connected, and only in ways their vendor terms allow. Some vendors limit API access to certain plans, restrict how data may be stored elsewhere or cap the number of requests. Those limits are checked before anything is built. API keys and credentials stay in your accounts. This is a marketing observation, not legal advice.

How we run an integration project

A free review

We start with a conversation about where double entry happens, which systems are involved, who uses each one, and what goes wrong today. We ask for a list of the products and plans you hold.

A custom proposal

The proposal sets out each connection, the source of truth and field mapping, one way or two way sync, how failures and duplicates are handled, the credentials needed and how testing will be done. Fees are quoted in writing. Any software licences are paid to the vendor and shown separately.

Build, test and hand off

Connections are built in your accounts, tested with sample records, checked by your team, then switched on. You receive the documentation and a short walkthrough for the people who will see alerts.

Support afterwards

If you choose ongoing support, each month we review failed records and alerts, apply vendor changes and adjust mappings as your processes change.

What API integration costs

Integration work is quoted in writing after the free review. Software licences, including any extra plan a vendor requires for API access, are paid to that vendor and shown separately from our fees.

What drives the quote

• How many systems are connected and how many separate feeds run between them.
• One way or two way sync, and how many fields are mapped.
• How well documented each vendor’s API is, and whether a test account exists.
• How much existing data needs cleaning or deduplicating before go live.
• Whether historical records are brought across or only new ones.
• Whether ongoing support and vendor change updates are included.

Free tools and connector apps

Some systems include basic connectors, and general connector apps can link popular products without code. They suit simple one way feeds. As rules grow (duplicates, two way sync, error handling, access control), many businesses find they need a direct integration they own and can document.

Choosing an integration partner and your next step

An integration touches customer data in every system it connects. Questions to ask any provider:

• Who owns the accounts? The answer should be you, including every API key, integration user and the documentation.
• Which system is the source of truth for each field, and will that be written down?
• What happens when a record fails, and who at my business is told?
• How will duplicates be prevented and existing ones cleaned up?
• Who keeps the integration working when a vendor changes its API?
• Will testing use sample records before real customers are touched?

Young companies setting up their first CRM and connections at the same time may find our page on a CRM for startups useful.

Your next step

Write down every product your business pays for, star the places where a person retypes orders, leads or invoices, and send that list to Canada Create. We will walk through it with you in a free integration review, then follow with a custom proposal covering mapping, sync and support, with our fees set out in writing. Call (416) 273-9030, Monday to Friday, 9 am to 6 pm, and Saturday, 10 am to 2 pm. After hours, our 24/7 AI agent answers the toll-free line, +1 (800) 808-9235, and we’ll follow up the next business morning. You can also reach us through our contact page. Expect our answer within one business day; you can also find us at 126 Willowdale Avenue, Suite 3, Toronto.