Back to CRM Data Hygiene

Integration and API Spec

The reference during the build: every tool connection, auth scope, field mapping, and error-handling rule.

4 pagesPDF · Technical
FS-DOC-05Technical

Integration and API Spec

CRM Data Hygiene Automation

[YourCompany.com] · Sales Department · Prepared by FullSpec · [Today's Date]

This document defines every integration point, API contract, credential requirement, field mapping, and error-handling rule for the CRM Data Hygiene automation. It is written for the FullSpec engineering team responsible for building and deploying the three-agent workflow. Each section below covers a discrete layer of the integration stack: tool inventory, per-tool configuration, cross-tool field mappings, orchestration design, and failure-mode behaviour. Nothing in this document is aspirational; all specifications reflect the confirmed tooling, volume, and build scope agreed for this engagement.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent(s)
HubSpot
CRM source for contact and deal pulls; write-back target for merges, enriched fields, and suppression flags
OAuth 2.0 (private app token)
Sales Hub Starter or higher (API write access required)
Agent 1, Agent 2, Agent 3
Clearbit
Contact and company enrichment API; returns job title, company size, and industry for incomplete records
API key (Bearer token in Authorization header)
Clearbit Enrichment (paid tier); free tier rate limits are insufficient
Agent 2
Slack
Delivers the weekly exceptions digest to the #sales-ops channel; alerts for enrichment failures and borderline duplicates
Slack Bot Token (OAuth 2.0, Bot scope)
Slack Free or Pro (Bot integration available on all plans)
Agent 3
Google Sheets
Hygiene audit log; one row appended per automation run recording counts and run metadata
OAuth 2.0 (service account JSON key or user OAuth token)
Google Workspace (any tier) or personal Google account
Agent 3
Automation platform
Orchestration layer; hosts all three agent workflows, manages scheduling, credential store, retry logic, and inter-agent data passing
Internal platform credential store; no external auth required
$49/month plan as per tooling budget
All agents (orchestration layer)
Before you connect anything: provision sandbox or test credentials for every tool listed above and validate each connection end-to-end in a non-production environment before any production credentials are entered into the credential store. HubSpot sandbox portals, a dedicated Clearbit test key with a low monthly cap, a Slack test workspace, and a staging Google Sheet must all be confirmed working before the live build proceeds.

02Per-tool integration detail

HubSpot

HubSpot is the primary CRM source and write-back target. The automation reads contact and deal records, performs merge operations on high-confidence duplicate pairs, writes enriched field values, and sets suppression properties. All access is via HubSpot's Private App API using a long-lived access token scoped to the minimum required permissions.

Auth method
OAuth 2.0 Private App token. Generate in HubSpot Settings > Integrations > Private Apps. Store the token value in the credential store as HUBSPOT_API_TOKEN. Token does not expire unless revoked.
Required scopes
crm.objects.contacts.read, crm.objects.contacts.write, crm.objects.deals.read, crm.objects.deals.write, crm.objects.companies.read, crm.schemas.contacts.read, crm.schemas.deals.read, crm.objects.contacts.merge
Webhook / trigger setup
No inbound webhook from HubSpot is required for the scheduled weekly run. For the new-contact creation trigger, configure a HubSpot Workflow (native automation) to POST to the automation platform's inbound webhook URL when contact lifecycle stage equals 'Lead' and record is newly created. Validate webhook payload signature using HubSpot's X-HubSpot-Signature-v3 header with the shared secret stored as HUBSPOT_WEBHOOK_SECRET.
Required configuration
Store the HubSpot Portal ID as HUBSPOT_PORTAL_ID in the credential store. Do not hardcode. Confirm the internal property names for the following before build: job title field (default: jobtitle), company size (default: numberofemployees), industry (default: industry), lifecycle stage (default: lifecyclestage), suppression flag (create a custom boolean property hs_suppressed if not present). Stale deal threshold (default: 30 days of no last_activity_date) must be stored as a configurable parameter STALE_DEAL_DAYS, not hardcoded.
Rate limits
HubSpot API enforces 100 requests per 10 seconds and 250,000 requests per day on Starter tier. At ~300 to 600 records/month (roughly 75 to 150 per weekly run), peak usage is well below limits. No throttling wrapper is required at current volume; implement a 100ms delay between batch write calls as a conservative guard. Merge endpoint counts as a write call.
Constraints
The merge endpoint (POST /crm/v3/objects/contacts/merge) is irreversible. Only call it for pairs with confidence score above the agreed threshold. The secondary record is deleted on merge; ensure unique data from secondary is appended to primary before merge call. Do not overwrite existing non-null field values on enrichment write-back.
// Primary endpoints used
GET  /crm/v3/objects/contacts?limit=100&after={paginationToken}
GET  /crm/v3/objects/deals?limit=100&after={paginationToken}
POST /crm/v3/objects/contacts/merge
PATCH /crm/v3/objects/contacts/{contactId}
PATCH /crm/v3/objects/deals/{dealId}
// Pagination: use 'paging.next.after' cursor; loop until no next cursor returned
Clearbit

Clearbit Enrichment is called by the Enrichment Agent for every contact record that has one or more empty priority fields (job title, company size, or industry). The API returns a structured JSON person and company object. Only confirmed, non-null values returned by Clearbit are written back to HubSpot; existing field values are never overwritten.

Auth method
API key passed as Bearer token in the Authorization header. Store as CLEARBIT_API_KEY in the credential store.
Required scopes
No OAuth scope model. The API key grants access to all Enrichment endpoints purchased under the plan. Confirm the account has the Person Enrichment and Company Enrichment endpoints enabled.
Webhook / trigger setup
Not applicable. Clearbit Enrichment is called synchronously per record via HTTP POST. No inbound webhook configuration required. For async enrichment (Reveal plan), a callback URL can be registered; not required for this build.
Required configuration
Store the monthly lookup cap as CLEARBIT_MONTHLY_LOOKUP_CAP (recommended: 2,000 to control spend at $99/month tier). Implement a counter in the orchestration layer that increments on each successful enrichment call and halts enrichment requests for the remainder of the month if the cap is reached, logging a warning to the exceptions digest. Prioritise enrichment for contacts associated with open deals before unassigned contacts.
Rate limits
Clearbit enforces 600 requests per minute on the standard paid tier. At current volume (75 to 150 contacts per weekly run), peak rate is approximately 2.5 requests per second, well within limits. No throttling needed. If volume scales above 500 records per run, add a 100ms inter-request delay as a precaution.
Constraints
Enrichment is best-effort; Clearbit returns null for fields it cannot confirm. Null values must not be written to HubSpot. Clearbit data must not overwrite any HubSpot field flagged in the ENRICHMENT_PROTECTED_FIELDS list (stored in credential store as a comma-separated string of HubSpot internal property names). GDPR note: Clearbit processes personal data; confirm data processing agreement is in place before production use.
// Enrichment endpoint
GET https://person.clearbit.com/v2/combined/find?email={contact_email}
// Response fields mapped to HubSpot
response.person.title       -> jobtitle
response.company.metrics.employees -> numberofemployees
response.company.category.industry -> industry
// Write only if HubSpot field is null AND field not in ENRICHMENT_PROTECTED_FIELDS
Slack

Slack is used exclusively as an output channel. The Deal Hygiene Agent composes a structured digest message and posts it to the designated #sales-ops channel once per weekly run. The message lists borderline duplicate pairs, stale deals awaiting rep confirmation, enrichment failures, and a run summary. No Slack data is read back into the automation.

Auth method
Slack Bot Token (xoxb- prefix) generated via a Slack App with Bot Token Scopes. Store as SLACK_BOT_TOKEN in the credential store. Store the target channel ID (not name) as SLACK_SALES_OPS_CHANNEL_ID.
Required scopes
chat:write, chat:write.public (if the bot is not a member of the channel). Do not request broader scopes. The bot must be invited to #sales-ops before the first run.
Webhook / trigger setup
Incoming webhook URL is an acceptable alternative to the Bot Token for posting only. If using an incoming webhook, store the URL as SLACK_WEBHOOK_URL and remove the Bot Token credential. Do not use both simultaneously. Incoming webhook approach is simpler but less flexible if additional Slack interactions are added later.
Required configuration
The digest message must use Slack Block Kit JSON for structured formatting. Store the base message template structure as a configuration object, not inline in the workflow. Include a run_id field in each message derived from the ISO 8601 run timestamp for traceability. SLACK_SALES_OPS_CHANNEL_ID must be stored in the credential store and not hardcoded.
Rate limits
Slack API enforces 1 message per second per channel for chat.postMessage on the Tier 3 rate limit bucket. This automation posts one message per weekly run. Rate limiting is not a concern at any foreseeable volume.
Constraints
Message payload must not exceed 3,000 characters per block or 50 blocks per message. If the exceptions list is unusually long (more than 40 line items), truncate and append a note directing the ops lead to the Google Sheets audit log for the full list. Never post contact PII (email addresses, phone numbers) directly in the Slack message body.
// Post message endpoint
POST https://slack.com/api/chat.postMessage
// Required payload fields
{
  "channel": "{SLACK_SALES_OPS_CHANNEL_ID}",
  "blocks": [ ...BlockKit JSON... ],
  "text": "CRM Hygiene Run Complete - {run_date}"
}
// Authorization header
Authorization: Bearer {SLACK_BOT_TOKEN}
Google Sheets

Google Sheets serves as the persistent hygiene audit log. After each weekly run, the Deal Hygiene Agent appends a single row to a designated audit sheet recording run metadata and counts. This log is read by the sales manager and ops lead but is never read back by the automation.

Auth method
OAuth 2.0 via a Google service account. Create a service account in Google Cloud Console, download the JSON key, and store the entire JSON key string as GOOGLE_SERVICE_ACCOUNT_JSON in the credential store. Share the target spreadsheet with the service account email address (editor role).
Required scopes
https://www.googleapis.com/auth/spreadsheets (read/write to spreadsheets). Do not use the broader drive scope. The service account only needs access to the single audit spreadsheet.
Webhook / trigger setup
Not applicable. Google Sheets is written to as a terminal action; no trigger or inbound webhook is used.
Required configuration
Store the target spreadsheet ID as SHEETS_AUDIT_LOG_SPREADSHEET_ID and the target sheet tab name as SHEETS_AUDIT_LOG_TAB_NAME (default: 'Hygiene Log') in the credential store. The sheet must have the following header row pre-created in row 1: run_id, run_date, trigger_type, contacts_scanned, duplicates_merged, duplicates_flagged, records_enriched, enrichment_failures, deals_flagged, deals_suppressed, run_duration_seconds. All subsequent rows are appended by the automation.
Rate limits
Google Sheets API enforces 300 write requests per minute per project and 60 requests per minute per user. Appending one row per weekly run generates negligible API usage. No throttling required.
Constraints
Do not use the spreadsheet for any computation or read-back; it is a write-only audit sink from the automation's perspective. Column order must match the header row exactly. If the sheet tab is renamed or the spreadsheet is moved, the SHEETS_AUDIT_LOG_TAB_NAME or SHEETS_AUDIT_LOG_SPREADSHEET_ID credential must be updated.
// Append row endpoint
POST https://sheets.googleapis.com/v4/spreadsheets/{SHEETS_AUDIT_LOG_SPREADSHEET_ID}/values/{SHEETS_AUDIT_LOG_TAB_NAME}!A1:K1:append?valueInputOption=USER_ENTERED
// Row payload (array order must match header)
[run_id, run_date, trigger_type, contacts_scanned, duplicates_merged,
 duplicates_flagged, records_enriched, enrichment_failures,
 deals_flagged, deals_suppressed, run_duration_seconds]
Integration and API SpecPage 1 of 4
FS-DOC-05Technical

03Field mappings between tools

The tables below document every field-level data transfer between tools, organised by agent handoff. Field names are shown in their exact API or internal property format. No field is written unless the source value is non-null and the destination field is confirmed empty (or the write is additive, such as an audit log append).

Agent 1 handoff: HubSpot to Deduplication Agent (record pull)

Source tool
Source field
Destination tool
Destination field
HubSpot
id
Dedup Agent working set
contact_id
HubSpot
properties.email
Dedup Agent working set
email
HubSpot
properties.phone
Dedup Agent working set
phone
HubSpot
properties.firstname
Dedup Agent working set
first_name
HubSpot
properties.lastname
Dedup Agent working set
last_name
HubSpot
properties.company
Dedup Agent working set
company_name
HubSpot
properties.jobtitle
Dedup Agent working set
job_title
HubSpot
properties.hs_object_id
Dedup Agent working set
hs_object_id
HubSpot
properties.createdate
Dedup Agent working set
created_at
HubSpot
properties.lastmodifieddate
Dedup Agent working set
last_modified_at

Agent 1 output to HubSpot: merge write-back (high-confidence pairs only)

Source tool
Source field
Destination tool
Destination field
Dedup Agent
primary_contact_id
HubSpot
primaryObjectId (merge body)
Dedup Agent
secondary_contact_id
HubSpot
objectIdToMerge (merge body)
Dedup Agent
confidence_score
HubSpot
not written; logged to audit row only
Dedup Agent
merge_reason
HubSpot
not written; logged to audit row only

Agent 2 handoff: Dedup Agent output to Clearbit (enrichment request)

Source tool
Source field
Destination tool
Destination field
HubSpot (via Agent 1)
properties.email
Clearbit API
email (query param)
HubSpot (via Agent 1)
id
Enrichment Agent working set
contact_id (for write-back reference)

Agent 2 output: Clearbit response to HubSpot (enrichment write-back)

Source tool
Source field
Destination tool
Destination field
Clearbit
person.title
HubSpot
jobtitle
Clearbit
company.metrics.employees
HubSpot
numberofemployees
Clearbit
company.category.industry
HubSpot
industry
Clearbit
company.name
HubSpot
company (write only if HubSpot company field is null)
Clearbit
person.name.givenName
HubSpot
firstname (write only if null)
Clearbit
person.name.familyName
HubSpot
lastname (write only if null)
Overwrite protection: before any PATCH call to HubSpot, the Enrichment Agent must read the current field value from the working-set record pulled in Agent 1. If the field is non-null, skip the write entirely. Do not issue a GET to HubSpot per field; use the already-fetched record object to evaluate nullability. Any field listed in ENRICHMENT_PROTECTED_FIELDS is skipped unconditionally regardless of null status.

Agent 3 handoff: HubSpot deal data to Deal Hygiene Agent

Source tool
Source field
Destination tool
Destination field
HubSpot
id
Deal Hygiene Agent working set
deal_id
HubSpot
properties.dealname
Deal Hygiene Agent working set
deal_name
HubSpot
properties.dealstage
Deal Hygiene Agent working set
deal_stage
HubSpot
properties.hs_lastmodifieddate
Deal Hygiene Agent working set
last_modified_at
HubSpot
properties.hubspot_owner_id
Deal Hygiene Agent working set
owner_id
HubSpot
properties.closedate
Deal Hygiene Agent working set
close_date
HubSpot
properties.amount
Deal Hygiene Agent working set
deal_value

Agent 3 outputs: Deal Hygiene Agent to Slack and Google Sheets

Source tool
Source field
Destination tool
Destination field
Deal Hygiene Agent
digest.stale_deals[]
Slack
blocks[].text (deal name, owner, days inactive)
Deal Hygiene Agent
digest.borderline_dupes[]
Slack
blocks[].text (contact pair, match score)
Deal Hygiene Agent
digest.enrichment_failures[]
Slack
blocks[].text (contact_id, failure reason)
Deal Hygiene Agent
run_summary.run_id
Google Sheets
run_id column
Deal Hygiene Agent
run_summary.run_date
Google Sheets
run_date column
Deal Hygiene Agent
run_summary.trigger_type
Google Sheets
trigger_type column
Deal Hygiene Agent
run_summary.contacts_scanned
Google Sheets
contacts_scanned column
Deal Hygiene Agent
run_summary.duplicates_merged
Google Sheets
duplicates_merged column
Deal Hygiene Agent
run_summary.duplicates_flagged
Google Sheets
duplicates_flagged column
Deal Hygiene Agent
run_summary.records_enriched
Google Sheets
records_enriched column
Deal Hygiene Agent
run_summary.enrichment_failures
Google Sheets
enrichment_failures column
Deal Hygiene Agent
run_summary.deals_flagged
Google Sheets
deals_flagged column
Deal Hygiene Agent
run_summary.run_duration_seconds
Google Sheets
run_duration_seconds column
Integration and API SpecPage 2 of 4
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Three discrete workflows, one per agent, hosted on the automation platform. Workflows execute sequentially: Agent 1 (Deduplication) completes before Agent 2 (Enrichment) starts; Agent 2 completes before Agent 3 (Deal Hygiene) starts. Inter-agent data is passed via a shared in-memory run context object keyed by run_id. No persistent queue or message broker is required at current volume.
Agent 1 trigger
Dual-trigger: (1) scheduled cron expression '0 7 * * 1' (Monday 07:00 in the account's local timezone, stored as SCHEDULE_TIMEZONE in the credential store); (2) inbound HTTP webhook from HubSpot new-contact workflow. Both triggers initialise the same workflow with trigger_type field set to 'scheduled' or 'webhook' respectively. Webhook signature validated using HMAC-SHA256 against HUBSPOT_WEBHOOK_SECRET before any processing begins. Reject and log any request failing signature validation.
Agent 2 trigger
Internal chained trigger. Agent 1 emits a run_context object on completion. Agent 2 subscribes to this internal completion event and starts immediately. No external webhook. If Agent 1 exits with an error status, Agent 2 must not start; the orchestration layer must propagate the failure and alert via Slack.
Agent 3 trigger
Internal chained trigger on Agent 2 completion, same pattern as Agent 2. Agent 3 also receives the cumulative run_context (updated by Agent 2 with enrichment counts and failure list) and uses it to compose the Slack digest and audit log row.
Credential store type
Platform-native encrypted secret store. All credentials referenced in workflows use variable references (e.g. {{HUBSPOT_API_TOKEN}}) and are never written as literal strings in workflow configuration, code nodes, or logs.
Scheduling timezone
Stored as SCHEDULE_TIMEZONE in the credential store. Default: America/New_York. Must be updated to match the account's operating timezone before go-live.
Stale deal threshold
Stored as STALE_DEAL_DAYS (integer, default: 30) in the credential store. Referenced by Agent 3 at runtime; not hardcoded in the workflow.
Duplicate confidence threshold
Stored as DEDUP_CONFIDENCE_THRESHOLD (float, 0.0 to 1.0, default: 0.85) in the credential store. Pairs scoring at or above this value are auto-merged; pairs scoring between 0.60 and 0.84 are flagged for human review; pairs scoring below 0.60 are discarded.

Credential store contents (all entries required before first run):

Credential store: all values are environment-scoped secrets. Never log, print, or expose these values in workflow output nodes.
// ── HubSpot ──────────────────────────────────────────────────────────
HUBSPOT_API_TOKEN              = "pat-na1-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
HUBSPOT_PORTAL_ID              = "12345678"
HUBSPOT_WEBHOOK_SECRET         = "whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

// ── Clearbit ─────────────────────────────────────────────────────────
CLEARBIT_API_KEY               = "sk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
CLEARBIT_MONTHLY_LOOKUP_CAP    = 2000
ENRICHMENT_PROTECTED_FIELDS    = "jobtitle,hs_lead_status"   // comma-separated HubSpot internal names

// ── Slack ─────────────────────────────────────────────────────────────
SLACK_BOT_TOKEN                = "xoxb-xxxxxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx"
SLACK_SALES_OPS_CHANNEL_ID     = "C0XXXXXXXXX"

// ── Google Sheets ─────────────────────────────────────────────────────
GOOGLE_SERVICE_ACCOUNT_JSON    = "{...full service account key JSON...}"
SHEETS_AUDIT_LOG_SPREADSHEET_ID = "1BxiMVs0XRA5nFMdKvBdBZjgmUUqptlbs74OgVE2upms"
SHEETS_AUDIT_LOG_TAB_NAME      = "Hygiene Log"

// ── Orchestration parameters ──────────────────────────────────────────
SCHEDULE_TIMEZONE              = "America/New_York"
STALE_DEAL_DAYS                = 30
DEDUP_CONFIDENCE_THRESHOLD     = 0.85
DEDUP_REVIEW_THRESHOLD_LOW     = 0.60
Integration and API SpecPage 3 of 4
FS-DOC-05Technical

05Error handling and retry logic

Every integration point in this automation has a defined failure behaviour. Unhandled exceptions must never fail silently. If a scenario is not covered by the retry and fallback logic below, the orchestration layer must catch the unhandled exception, write a structured error entry to the run_context, and include it in the Slack digest under an 'Automation Errors' section before terminating the run.

Integration
Scenario
Required behaviour
HubSpot / Agent 1
GET contacts API returns HTTP 429 (rate limit)
Retry with exponential backoff: wait 2s, 4s, 8s for up to 3 attempts. If still 429 after 3 retries, halt Agent 1, post 'HubSpot rate limit exceeded' alert to Slack, and abort the run. Log full error to audit row with status 'FAILED_RATE_LIMIT'.
HubSpot / Agent 1
Merge API returns HTTP 409 (conflict: record already merged)
Treat as non-fatal. Skip the merge for that pair, log the pair IDs and response to run_context as 'already_merged', and continue processing remaining pairs. Do not retry.
HubSpot / Agent 1
Merge API returns HTTP 500 or 503 (server error)
Retry up to 3 times with 5s fixed delay. If all retries fail, mark the pair as 'merge_failed' in run_context, include in Slack digest under borderline duplicates for manual review, and continue the run.
HubSpot webhook / Agent 1
Inbound new-contact webhook fails HMAC-SHA256 signature validation
Reject immediately with HTTP 401. Do not process payload. Log the event (timestamp, source IP) to the platform's internal error log. Do not alert Slack for individual rejections; alert only if more than 5 rejections occur within 10 minutes.
Clearbit / Agent 2
Enrichment API returns HTTP 404 (person not found)
Treat as expected. Increment enrichment_failures counter in run_context. Do not retry. Log the contact_id and email domain (not full email) to the failures list for the Slack digest. Continue to next record.
Clearbit / Agent 2
Enrichment API returns HTTP 402 (monthly cap reached)
Halt all further Clearbit calls for the remainder of the run. Post an immediate Slack alert: 'Clearbit monthly lookup cap reached. Remaining contacts not enriched this run.' Log count of un-enriched records to run_context. Continue to Agent 3 without enrichment for remaining records.
Clearbit / Agent 2
Enrichment API returns HTTP 503 or network timeout (>10s)
Retry up to 2 times with 3s delay. If still failing, mark the contact as 'enrichment_timeout' in run_context, skip it, and continue. Include total timeout count in Slack digest.
HubSpot PATCH / Agent 2
Enrichment write-back returns HTTP 400 (invalid field value)
Log the contact_id, field name, and rejected value to run_context. Do not retry. Flag as 'enrichment_write_failed' in the Slack digest. The ops lead must review and correct the field mapping. Continue to next record.
Slack / Agent 3
chat.postMessage returns HTTP 429 or network error
Retry up to 3 times with 5s delay. If digest cannot be posted after 3 attempts, write the full digest payload to the Google Sheets audit log as a JSON string in an 'unposted_digest' column and log a platform-level error. The run is marked 'PARTIAL_SUCCESS'.
Google Sheets / Agent 3
Append row returns HTTP 403 (service account permission denied)
Do not retry. Log the error to the platform's internal error log. Post a Slack alert: 'Audit log append failed: permission denied. Check service account sharing on the spreadsheet.' Mark run status as 'PARTIAL_SUCCESS'. The Slack digest is still posted if available.
Google Sheets / Agent 3
Append row returns HTTP 503 or timeout
Retry up to 3 times with 4s delay. If all retries fail, store the audit row payload in run_context and include it in the Slack digest as a formatted fallback so the ops lead can paste it manually. Mark run status 'PARTIAL_SUCCESS'.
Orchestration layer / all agents
Unhandled exception in any workflow node
The orchestration layer must catch all unhandled exceptions via a global error handler. On catch: write error details (node name, error type, stack trace summary) to run_context; post a Slack alert to SLACK_SALES_OPS_CHANNEL_ID with the run_id and error summary; append a partial audit row with status 'FAILED_UNHANDLED'. Never allow a silent failure. If the Slack post itself fails, write to the platform's internal dead-letter log.
Retry budgets are intentional: the automation runs on a weekly cadence and a modest batch of 75 to 150 records. Aggressive retry loops are not required and could exhaust rate limits. The priority is correct partial output with clear failure reporting over blocking retries that delay the digest. Every run must produce a Slack message and an audit log row, even if their content is a failure summary.
Support contact
support@gofullspec.com
Process owner
[Your name]
Owner email
[Rep email]
Integration and API SpecPage 4 of 4

More documents for this process

Every document generated for CRM Data Hygiene.

Launch Plan
Operations · Owner
View
ROI and Business Case
Finance · Owner
View
Process Runbook / SOP
Operations · Owner
View
Developer Handover Pack
Technical · Developer
View
Test and QA Plan
Quality · Developer
View