Integrating Business, Communication & Productivity Systems: CRM, ERP, Slack, Email, Google Workspace & Microsoft 365

Real integrations connect to the systems a company actually lives in: the business systems that hold the records (CRM, ERP, payments), the communication tools where people work (Slack, email), and the productivity suites and databases underneath (Google Workspace, Microsoft 365, the database). This tutorial covers all three families as one chapter, because they share the same underlying pattern — read real responses, scope auth tightly, paginate, respect rate limits, write idempotently.

Table of Contents

• Part 1: Business System Integrations
• Why These Systems Matter
• CRM Integration
• ERP Integration
• Payment Integration
• Part 2: Communication Integrations
• Why Communication Integrations Matter
• Slack: The Basics
• Slack Authentication
• Sending a Message to a Channel
• Posting as the Bot vs as a User
• Slack Webhooks: The Simple Path
• Email: The Two Kinds
• Transactional Email with an API
• Email Best Practices
• Part 3: Productivity Suites & Databases
• Why These Two Suites
• The Shared Pattern: OAuth + Scopes
• Google Workspace Integration
• Reading Gmail / Writing to Sheets
• Microsoft 365 Integration
• Outlook / Excel via Microsoft Graph
• Database Integration: The Foundation
• Database Integration in a Suite Context
• The Shared Playbook

Part 1: Business System Integrations

Why These Systems Matter

CRM, ERP, and payment systems are the systems of record — they hold the facts a business legally and operationally depends on: who customers are, what was ordered, what was paid. Integrations to them move real, sensitive business data through your code, so the stakes are higher and the discipline matters more.

CRM Integration

A CRM (Customer Relationship Management) system tracks a company's interactions with customers and prospects — contacts, companies, deals, notes, emails. The big ones: Salesforce, HubSpot, Zoho, Microsoft Dynamics.

CRMs live on the sales/front side. The pattern you'll build most: sync records in and out (contacts, companies, deals) and push activity (notes, events, emails) back into the timeline so sales sees everything in one place.

import os, requests

# read new deals from the CRM
resp = requests.get(
    "https://api.hubspot.com/crm/v3/objects/deals",
    headers={"Authorization": f"Bearer {os.getenv('HUBSPOT_TOKEN')}"},
    params={"limit": 100},
    timeout=30,
)
resp.raise_for_status()
for d in resp.json()["results"]:
    print(d["id"], d["properties"].get("amount"))

Explanation: HubSpot (and most CRMs) expose their records via REST object APIs. The pattern is "hit an object endpoint, paginate, map to your shape" — exactly the work of Tutorials 1–3, now against a domain object.

Best Practices for CRM sync:

• Deduplicate on a stable id — CRMs allow duplicates; use their id and your external_id to upsert, not append (Tutorial 5).
• Mind the rate limits — CRM APIs are strict; batch your writes.
• Avoid two-way firestorms — if a CRM pushes back to your system and you push back to the CRM, you can loop forever. Pick a primary source of truth per field and reconcile one-way.
• Know the sandbox — nearly every CRM has a test environment; test there.

ERP Integration

An ERP (Enterprise Resource Planning) system runs a company's back-office operations: finance, inventory, purchasing, manufacturing, HR, and accounting. Think SAP, NetSuite, Microsoft Dynamics, Odoo. It's often the "single source of truth" for the money.

ERPs are heavy — the data model is enormous and often not where you'd expect. Integration usually means pulling a narrow slice: orders, inventory levels, invoices, or stock on hand. It's more about reading and keeping consistent than about creating data.

# check inventory levels from the ERP
import requests, os
resp = requests.get(
    "https://api.netsuite.com/services/rest/record/v1/item",
    headers={"Authorization": f"Bearer {os.getenv('NETSUITE_TOKEN')}"},
    timeout=30,
)
resp.raise_for_status()
print("items:", len(resp.json().get("items", [])))

Explanation: NetSuite uses REST against its record model; the pattern (auth + GET + paginate) is the same, but you must learn its object names and fields. Don't guess the schema — verify against a real response (Tutorial 3).

The ERP Reality:

• Large scope — an ERP can model the whole business. Scope your integration to one slice (e.g., just inventory, just invoices), not "everything."
• Legacy/slow — some ERP endpoints are slow; build with generous timeouts and batch carefully.
• Records vs services — some ERPs still expose old SOAP/web-services interfaces alongside REST. Prefer REST when offered; match whatever's actual.
• Be the good citizen — you are touching the system-of-record for money and inventory. Every write must be testable and auditable; prefer reading until you're sure.

Best Practice: treat the ERP as a slow, precious system. Pull what you need, push nothing you don't have to, and always cross-check against a real "does this inventory number match reality?" test rather than trusting the doc.

Payment Integration

A payment integration lets your app take money (and handle refunds, subscriptions, invoices) through a processor — Stripe, PayPal, Braintree, Adyen, or Square. This is the closest to a pure developer-friendly API, but it has unique rules: security, PCI, and crypto.

PCI & Cards

If your app handles, stores, or transmits raw card numbers, you bring on PCI DSS compliance — a heavy set of security obligations.

Best Practice — never touch the card data yourself. Use the processor's hosted page (Stripe Checkout, Stripe Payment Element, PayPal) so the card number never passes through your server. That instantly removes you from almost all PCI scope. You only receive a token and the amount.

The Stripe-Style Pattern

Payment APIs are usually clean and well-documented:

import os, stripe
from flask import Flask, request

stripe.api_key = os.getenv("STRIPE_SECRET_KEY")
app = Flask(__name__)

@app.route("/checkout", methods=["POST"])
def checkout():
    # 1. create a payment intent server-side
    intent = stripe.PaymentIntent.create(
        amount=1999,          # minor units: 19.99 in cents
        currency="usd",
    )
    # 2. pass only the *client secret* to the frontend
    return {"client_secret": intent["client_secret"]}

Explanation: you never touch the card. The server creates a PaymentIntent; the frontend completes card entry against Stripe using only a short-lived client_secret. Amounts are minor units (cents) as integers — never floats.

Payment Integration Habits:

• Never float money — 0.1 + 0.2 breaks accounting (Data Engineering Tutorial 1). Store amounts as integers in minor units (1999 = $19.99).
• Webhooks are essential — the authoritative result of a charge arrives by webhook (charge.succeeded), not by reading the API response synchronously. Verify signatures and deduplicate by payment id (Tutorial 3).
• Test on cards / test keys — use the processor's test mode and its dummy card numbers (e.g., Stripe's 4242…) before real keys. Refunds, disputes, and failures all need an integration path.
• Handle idempotency keys — if a request times out, a retry with the same idempotency key (provided by processors like Stripe) won't double-charge the customer. This is where the POST charge must be safe to retry.

Part 2: Communication Integrations

Why Communication Integrations Matter

Systems that only hold data are half an integration — the other half is delivering the result to a human. Slack and email are how that happens: an order lands → Slack notifies ops; an invoice is ready → email sends it to the customer. These integrations are simple in mechanics and easy to get wrong in etiquette and deliverability.

Slack: The Basics

Slack has bots (apps that act under their own identity), channels (public/private rooms), direct messages (DMs), and incoming webhooks (a URL that posts a message without full app plumbing). You can send plain text or formatted blocks (rich messages with fields, buttons, headers).

Slack Authentication

The two ways your code gets permission to talk to Slack:

• App token (OAuth) — you build a Slack app, grant scopes like chat:write, and store the resulting bot token (Tutorial 2's OAuth). This is the flexible, production path.
• Incoming webhook — Slack gives you a URL; you POST a JSON payload to it. Zero scopes, zero OAuth setup — ideal for quick notifications.

Sending a Message to a Channel

With a bot token, use the official SDK or raw requests:

import os
from slack_sdk import WebClient

client = WebClient(token=os.getenv("SLACK_BOT_TOKEN"))
res = client.chat_postMessage(
    channel="C12345678",            # or a channel name like "#ops"
    text="A new order just arrived!",
)
print(res["ok"])

Explanation: we post a text message to one channel using the bot's token. res["ok"] tells us whether Slack accepted it. The bot must be invited to the channel first, or Slack returns a not_in_channel error.

Posting as the Bot vs as a User

• As the bot — messages come from the app's own identity; the bot must be a member of the channel. Simple and predictable.
• As a user (impersonation) — your app posts on behalf of a user via their token (OAuth with chat:write + user scopes). Useful for "schedule on my calendar" style flows, but it uses that user's permissions.

Best Practice: default to bot posts. Impersonation is powerful but confusing (whose messages are whose?) and needs the user's own OAuth consent.

Slack Webhooks: The Simple Path

When you don't need a full app, an incoming webhook is one POST:

import os, requests, json

webhook_url = os.getenv("SLACK_WEBHOOK_URL")
requests.post(
    webhook_url,
    json={"text": "Deploy finished ✅", "username": "deploy-bot"},
    timeout=30,
)

Explanation: we POST a JSON payload to Slack's webhook URL; Slack posts it to the configured channel. No token, no SDK. Great for alerts, CI notifications, and scripts — but limited (no dynamic channels, no user interactions).

Email: The Two Kinds

Email integration splits into two very different jobs:

• Transactional email — triggered, one-to-one, account-specific (order confirmation, password reset, invoice). Best done with an API like SendGrid, Postmark, or Amazon SES.
• Marketing/bulk email — newsletters, drip campaigns. That's a different, regulated world (CAN-SPAM, opt-in/opt-out) handled by ESPs like Mailchimp — often not something your integration owns.

This section covers transactional email, which is what integrations most often need.

Transactional Email with an API

Transactional APIs are simple: send a from, to, subject, and body, and they handle delivery (and often retries, opens, bounces). Example with SendGrid:

import os, requests

resp = requests.post(
    "https://api.sendgrid.com/v3/mail/send",
    headers={"Authorization": f"Bearer {os.getenv('SENDGRID_KEY')}"},
    json={
        "personalizations": [{"to": [{"email": "customer@acme.com"}]}],
        "from": {"email": "no-reply@yourapp.com"},
        "subject": "Your invoice",
        "content": [{"type": "text/plain", "value": "Invoice #1042 is ready."}],
    },
    timeout=30,
)
print(resp.status_code)   # 202 Accepted → queued for delivery

Explanation: we hand the email to SendGrid's API as JSON. The response 202 means it's accepted for delivery — actual delivery, bounces, and retries are handled by the provider, not your code.

Best Practice: send transactional email only via an API (or SMTP relay), not by connecting your app directly to someone's mail server — deliverability, SPF/DKIM, and bounces are the provider's job.

Email Best Practices

• Never send from raw SMTP if you can avoid it — use a provider that handles SPF/DKIM/DMARC, warm-up, and bounce handling, or your mail goes to spam or isn't delivered at all.
• Watch rate limits — email APIs throttle; batch and respect 429 (Tutorial 6).
• One-to-one, not spam — transactional mail should be triggered by a real action the user took; every message needs an unsubscribe path for marketing-style mail.
• Template variables, not raw HTML concatenation — build the body server-side or use the provider's templates; escape dynamic content to avoid HTML injection.

They often pair: a webhook (Tutorial 3) fires → Slack notifies the team → email confirms the customer.

Part 3: Productivity Suites & Databases

Why These Two Suites

Google Workspace and Microsoft 365 are where business users already live. Integrations to them turn your system from "something the customer visits" into "something that shows up where they work." Email, calendars, spreadsheets, files, and chats are all reachable — each behind an API, all under one auth umbrella per vendor.

The Shared Pattern: OAuth + Scopes

Both suites use OAuth 2.0 (Tutorial 2) as the gate, and both are strict about scopes — you must declare, per user, exactly which slice you're allowed to touch (e.g., "read email only," "write to one sheet").

You request:  https://www.googleapis.com/auth/gmail.readonly
              https://www.googleapis.com/auth/spreadsheets
User approves → you get a scoped token → call only those APIs

Best Practice: request the narrowest scopes that work. The suites review apps that ask for broad scopes, users distrust them, and a narrow scope limits the blast radius if a token leaks. Use the official client libraries — they handle token refresh (Tutorial 2) for you.

Google Workspace Integration

Google's Google API Client (for Python, etc.) turns the REST calls of Tutorial 1 into method calls. A "read the subject lines of the last emails" example:

from googleapiclient.discovery import build
import os

creds = build_creds_from_oauth(os.getenv("GOOGLE_CREDENTIALS_FILE"))
service = build("gmail", "v1", credentials=creds)

msgs = service.users().messages().list(
    userId="me", maxResults=5).execute().get("messages", [])
for m in msgs:
    detail = service.users().messages().get(userId="me", id=m["id"]).execute()
    subject = next(
        (h["value"] for h in detail["payload"]["headers"] if h["name"] == "Subject"),
        "(no subject)")
    print(subject)

Explanation: we build an authenticated Gmail service from an OAuth credential file, list messages, and read each message's headers to pull the subject. The auth is the hard part; once built, the calls read like plain REST.

Reading Gmail / Writing to Sheets

Writing a row into Google Sheets uses a similar service — you point at a spreadsheet id and append values:

service = build("sheets", "v4", credentials=creds)
values = [["acme.com", "2026-08-19", "paid"]]
body = {"values": values}
service.spreadsheets().values().append(
    spreadsheetId=os.getenv("SHEET_ID"),
    range="Sheet1!A1",
    valueInputOption="USER_ENTERED",
    body=body,
).execute()

Explanation: we append one row to a named spreadsheet. Sheets is a frequent FDE target precisely because non-technical stakeholders can read the result without any tooling.

Calendar & Drive: calendar.events().insert(...) for events (mind time zones and recurring events); drive.files() for file access, often paired with webhooks (Tutorial 3) so you know when a file changes.

Microsoft 365 Integration

Microsoft's unified API is Microsoft Graph — one endpoint covering Outlook, Excel, Teams, SharePoint, OneDrive, and more. Auth is OAuth 2.0 (often with Azure AD). A "read my next meeting" example:

import os, requests

token = get_msal_token()   # OAuth via Microsoft Authentication Library (MSAL)
headers = {"Authorization": f"Bearer {token}"}
resp = requests.get(
    "https://graph.microsoft.com/v1.0/me/events",
    params={"$top": 5, "$orderby": "start/dateTime"},
    headers=headers,
    timeout=30,
)
resp.raise_for_status()
for ev in resp.json()["value"]:
    print(ev.get("subject"), ev["start"].get("dateTime"))

Explanation: Graph returns our calendar events. Note the query params ($top, $orderby) — Graph uses a slightly different query syntax than plain REST, another reason to read its docs rather than guess. The same graph.microsoft.com/v1.0 host serves mail (/me/messages), Excel, and everything else.

Outlook / Excel via Microsoft Graph

Teams & SharePoint: post messages and build bots under Graph (resembling the Slack patterns of Part 2 but using Graph endpoints); file access via /me/drive and SharePoint sites for document flows, paired with webhooks for change notifications.

Note: Microsoft's auth surface is bigger than Google's — expect tenant/app registration, and grant scopes like Mail.Read, Calendars.ReadWrite. MSAL handles token refresh; don't hand-roll it.

Database Integration: The Foundation

Beneath every suite integration is the same root need: getting data in and out of a database. This is where your Data Engineering work comes together. The pattern is direct and well-trodden:

import os
import psycopg2

conn = psycopg2.connect(os.getenv("DATABASE_URL"))
with conn.cursor() as cur:
    cur.execute(
        "SELECT id, email FROM users WHERE active = %s LIMIT %s",
        (True, 100),
    )
    rows = cur.fetchall()
print(rows)

Explanation: we connect to Postgres from our code and run a parameterized SELECT. The %s placeholders (never f-string interpolation) both prevent SQL injection and keep the query readable.

Reads, Writes, and Schemas:

• Reads — the common integration job: pull the slice you need.
• Writes — higher stakes; use idempotent upserts (ON CONFLICT DO UPDATE, Data Engineering Tutorial 5) so reruns don't duplicate.
• Schema — know the columns before you write. A schema mismatch is the #1 surprise when pairing a database with a suite API.

Best Practice: every database write in an integration should be idempotent and logged (rows-in vs rows-out), the same hardening Data Engineering Tutorial 5 teaches. Databases don't forgive silent duplicate rows.

Database Integration in a Suite Context

Putting it together, the archetypal FDE flow combines all three families:

  Database ──▶ (read orders) ──▶ Google Sheets (share with finance)
  Webhook ───▶ (new event)  ──▶ Postgres (record it) ──▶ Slack (notify)
  Outlook ───▶ (meeting)    ──▶ Database (log it)    ──▶ Calendar (block)

The shared rules across every leg: scoped OAuth or a well-guarded key, narrow access, idempotent writes, and observation. Get those right and the specific system barely matters.

The Shared Playbook

Every system-specific detail above focusses down to the same steps you now know:

1. Read real responses first; don't trust only the docs (Tutorial 3).
2. Auth with a token — key or OAuth, scoped (Tutorial 2).
3. Paginate and respect rate limits (Tutorial 6).
4. Make writes idempotent (external ids, upsert keys) (Tutorials 1, 5).
5. Use webhooks where result truth comes asynchronously (payments) or push matters (Tutorial 3).
6. Sandbox-first, production last, keys separated.