Course B · Module B1 Production · Lesson 3 of 18

Integrate Data

Pull in and sync data from the other systems your business already runs on — so nothing lives in a silo.

~14 min · Have a list of the tools your business uses today · Prereq: B2 Databases

Your new app doesn't live in isolation. Your business already runs on a CRM, a payment processor, a spreadsheet, an email platform — and your customers expect everything to stay in sync. Manually copying data between systems is how errors creep in and hours disappear. Your single win today: by the end you'll understand the three main ways data moves between apps, and know which one to reach for at each stage of your build.

The API: the door every modern app leaves open

In Course A you met the idea of an API — the "waiter" that carries requests between your app and another service. Let's make it concrete.

Every serious software service — Stripe, HubSpot, Google Sheets, Mailchimp — has a set of doors in its back wall. Each door is labeled: "get all customers," "create an invoice," "update a contact." You knock on a door by sending an HTTP request with the right address and a key that proves you're allowed in. The service opens the door and hands you back data (or confirms it did the thing).

Those doors, taken together, are the API. You don't need to know how the service works inside — just which door to knock on and what it will hand you back.

When your app calls Stripe to charge a card, it's knocking on Stripe's "create charge" door. When it calls your CRM to log a new contact, it's knocking on a "create contact" door. The AI can write all of this code for you — you just need to know which service you want to talk to and what you want it to do.

Three ways to move data: import, sync, event

CSV import / exportThe simplest move: download a spreadsheet from one system, upload it to another. Good for a one-time migration or occasional manual refresh. No code needed.

Scheduled syncA script (or no-code tool like Zapier) that runs every hour or every night: "fetch all new orders from Stripe and write them to my database." Keeps data fresh automatically.

Webhook (event-driven)The other service calls you the moment something happens — no waiting for the schedule. Stripe fires a webhook the instant a payment completes; your app gets the data in real time.

Start with CSV import when you're just moving a one-off dataset. Move to scheduled sync when you need regular freshness. Use webhooks when you need to react immediately — a payment confirmation, a signup, a cancellation.

One-way vs two-way sync

Before building any integration, decide the direction of truth:

One-way sync

Data flows in one direction only. Your CRM is the source of truth; your app reads from it but never writes back. Simple, predictable, easy to debug. Start here whenever possible.

Two-way sync

Both systems can change the data and must stay in agreement. Powerful but far harder: what happens when both sides change the same record at the same time? That's a conflict, and you need a rule to resolve it. Only build this when the business genuinely needs it.

Keeping data fresh and avoiding duplicates

Two things go wrong most often in integrations: data goes stale (the sync breaks silently and nobody notices) and records get duplicated (the sync runs twice and writes the same row twice).

Build these four habits in from the start:

Use a unique key. Every record should have a field that proves it's that specific thing — an order ID from Stripe, a contact ID from your CRM. Before writing a record, check whether that ID already exists. If it does, update; if it doesn't, create. This pattern is called upsert and prevents duplicates automatically.
Log every sync run. Write a timestamp and a count ("synced 14 records at 03:00") somewhere you can check. A sync that ran and found nothing is fine; a sync that never ran at all looks identical from the outside until you check the log.
Alert on failure. Set up a simple notification (email, Slack) if the sync job errors. Silent failures are the worst kind.
Test with real data, carefully. Run the integration against a small batch first. Check what landed in your database before turning on the full firehose.

No-code tools (Zapier, Make) are your fastest path to a first integration. For most "fetch data from A, write it to B" jobs, a Zap or a Make scenario is faster than code and easier to debug. You can always replace it with code later once you've confirmed the pattern works. Don't over-engineer early.

Check yourself

Answer before opening — recalling it is what makes it stick.

You want to show a customer's payment status in your app the moment Stripe processes their payment. Import, scheduled sync, or webhook?

Webhook. "The moment it happens" is the definition of event-driven. A scheduled sync would introduce a delay (up to an hour if the sync runs hourly). A webhook fires in real time — Stripe calls your app immediately when the payment completes.

Your nightly sync has been running for two weeks. You check the database and find the same 50 orders duplicated three times each. What did you forget to build?

An upsert check — checking whether the record's unique ID already exists before writing. Without this, each sync run creates new rows instead of updating existing ones. The fix: before inserting, look up the order's Stripe ID; if it's already there, update the row instead of adding a new one.

What's the main risk of a two-way sync that a one-way sync doesn't have?

Conflicts — two systems changing the same record simultaneously with no agreed rule for which one wins. One-way sync has a single source of truth, so the direction of authority is always clear. Two-way syncs require a conflict-resolution strategy and are significantly harder to debug.