sonal`. Legacy Infusionsoft field names from 2006. Phone numbers have the same pattern: `PHONE1`, `PHONE2`, `PHONE3`, plus a separate `type` field. The custom fields are worse. Custom field `id: 7` contains `"Meal Plan Download"`. Custom field `id: 23` contains `"2026-01-15"`. Custom field `id: 45` contains `"3"`. Mark has no idea what these fields represent without querying the custom field definitions: ```bash GET https://api.infusionsoft.com/crm/rest/v2/contacts/model Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... ``` The model endpoint returns the full field schema. Custom field 7 is "Lead Source." Custom field 23 is "First Opt-In Date." Custom field 45 is "Email Opens." The field names exist only in the schema definition — they are not returned alongside the field values. Mark must join the two datasets client-side: query the model once, cache the field ID-to-name mapping, then apply it to every contact response. Brandon's Keap account has 67 custom fields. Forty-three were created by previous integrations, templates, and default imports from the Infusionsoft era. Many have cryptic names: `_LeadScore2`, `_ActionSequence`, `_OrderFormField1`, `_DecisionTree`. Mark has no way to determine which fields are actively used and which are abandoned artifacts. The tags are numeric IDs: `[142, 156, 203]`. Tag 142 might be "Downloaded Meal Plan." Tag 156 might be "Nurture Sequence — Email 3." Tag 203 might be "VIP." Mark must query the tags endpoint to resolve names: ```bash GET https://api.infusionsoft.com/crm/rest/v2/tags?limit=1000 ``` Brandon has 312 tags. Many are duplicates or near-duplicates: "Nurture Sequence," "Nurture_Sequence," "nurture-sequence," "NurtureSequence_OLD." The tag taxonomy is a fossil record of every campaign Brandon and his business coach ever created. ## The Two-API Problem Mark needs to enroll qualified contacts into the nurture email sequence. Email sequences in Keap are called "campaigns" — but they are not managed through the REST API. Campaign automation — the reason Brandon chose Keap in the first place — runs on the legacy XML-RPC API. Mark queries the available campaigns through REST: ```bash GET https://api.infusionsoft.com/crm/rest/v2/campaigns ``` The response returns campaign metadata: name, status, created date. But to add a contact to a campaign sequence, Mark must use the XML-RPC endpoint: ```xml ContactService.addToCampaignSequence api_key_here 14523 47 1 ``` XML-RPC. In 2026. The parameters are positional: API key, contact ID, campaign ID, sequence ID. No named parameters. No JSON. No self-describing payload. The contact ID `14523`, the campaign ID `47`, and the sequence ID `1` are magic numbers that Mark must discover through separate queries. The XML-RPC API uses a different authentication mechanism — a legacy API key from Settings > General, not the OAuth access token. Mark now needs two sets of credentials: OAuth for the REST API and a legacy API key for XML-RPC. The XML-RPC API has its own rate limit: 25 requests per second, separate from the REST API's daily quota. But the REST API's daily quota is the real constraint. ## The Daily Quota Wall Mark has been assembling Brandon's subscriber data: contacts, custom field definitions, tag names, campaign metadata. He checks his API usage: ``` X-RateLimit-Limit: 1500 X-RateLimit-Remaining: 847 X-RateLimit-Reset: 2026-02-08T00:00:00Z ``` Keap's REST API allows 1,500 requests per day. Not per hour. Not per minute. Per day. Mark has consumed 653 requests querying 340 contacts (4 pages), the custom field model (1 request), 312 tags (1 request), campaigns (1 request), and then querying individual contact details for email engagement data — because the list endpoint does not return engagement metrics. To build th