Practical coding & SQL for GTM

The API checklist

Almost every enrichment, CRM and sending tool exposes a REST API. Before you wire one up, answer:

• Auth: API key in a header, OAuth, or both? Where will the secret live (never in a shared table cell)?
• Pagination: cursor or page number? What tells you there are no more pages?
• Rate limits: requests per second or per day, and what does the 429 response look like?
• Errors: which codes are worth retrying (429, 5xx) and which mean stop (400, 401, 404)?
• Cost: is each call billed, and does a "no result" still cost a credit?

Normalise before you match

Most GTM data bugs are matching bugs. Normalise domains by lowercasing, stripping protocol, "www." and paths (https://www.Acme.io/about → acme.io). Strip legal suffixes from company names only for display, never as a join key. Standardise titles into buckets ("VP Sales", "Head of Sales", "SVP, Revenue" → sales leadership) with a lookup table you can edit, not a giant nested IF.

SQL patterns you'll use every week

Once CRM and sequence data land in a warehouse, these four patterns answer most questions:

• Latest record per entity: ROW_NUMBER() OVER (PARTITION BY domain ORDER BY updated_at DESC) = 1.
• Funnel counts: COUNT(DISTINCT CASE WHEN stage >= 'meeting' THEN contact_id END) by campaign.
• First touch: MIN(activity_at) per contact, joined back to see which campaign started the relationship.
• Duplicate finder: GROUP BY normalised_domain HAVING COUNT(*) > 1.

Use AI to write code, not to own it

AI coding assistants are excellent for GTM glue: a webhook handler, a parser, a script that backfills a field. Treat their output like a junior's pull request. Run it on a handful of real rows including an empty value, a unicode name and a malformed domain. Check that it handles the second page and the rate-limit response. If you can't explain each line, you can't debug it when it breaks at 2 AM during a 20,000-row run.