Back to Support Reporting & Insights

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

Support Reporting and Insights

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

This document is the authoritative integration reference for the Support Reporting and Insights automation. It covers every tool in the pipeline, the exact authentication configuration and permission scopes required, field-level data mappings between agents, the orchestration layout and credential store structure, and the defined error-handling behaviour for every integration point. The FullSpec team uses this specification during build, and it remains the canonical technical reference for any future change to the pipeline.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agents
Zendesk
Source of all ticket and CSAT data; queried via REST API on schedule
API token (Bearer)
Suite Team or above (API access required)
Agent 1 (Data Fetch)
Google Sheets
Data store for raw ticket records and calculated metrics summary tab
OAuth 2.0 (service account)
Google Workspace or free personal account
Agent 1 (Data Fetch), Agent 2 (Reporting)
Looker Studio
Live visual dashboard connected to Google Sheets data source
OAuth 2.0 (Google account delegation)
Free (Google account required)
Agent 2 (Reporting)
Gmail
Scheduled report email delivery to manager distribution list
OAuth 2.0 (Gmail send scope)
Google Workspace or Gmail account
Agent 3 (Distribution)
Slack
Real-time headline summary posted to support channel
OAuth 2.0 (Bot token)
Free or paid Slack workspace
Agent 3 (Distribution)
Notion
Persistent reporting log with per-period headline figures and links
OAuth 2.0 (integration token)
Free or paid; Notion API access required
Agent 3 (Distribution)
Orchestration layer
Hosts all three agent workflows, manages schedules, credentials, and inter-agent triggers
Internal credential store (no external auth)
N/A — platform selected at build time
All agents
Before you connect anything: provision sandbox or test credentials for every tool listed above and validate each connection in a non-production environment before introducing live production credentials. For Zendesk, use a sandbox subdomain if available. For Google Sheets and Gmail, use a dedicated test Google account. For Slack, use a private test channel. For Notion, use a test workspace. No production data should flow through any integration until all connection tests pass.

02Per-tool integration detail

Zendesk

Queried by the Data Fetch Agent (Agent 1) on a scheduled basis to retrieve all tickets in the configured reporting window. No webhook is used; the agent polls the REST API on the automation schedule.

Auth method
API token authentication. Request header: Authorization: Bearer {base64(email/token:api_token)}. Token generated in Zendesk Admin > Apps and Integrations > Zendesk API > API Tokens.
Required scopes
tickets:read, users:read, satisfaction_ratings:read. Read-only scopes are sufficient; no write permissions are required for this integration.
Trigger setup
No webhook. The orchestration layer fires a scheduled poll (daily at 07:00, weekly on Monday at 08:00, monthly on the 1st at 08:00 in the account timezone). Each poll calls the Search API with a date-range filter for the relevant reporting period.
Required configuration
Store in credential store: ZENDESK_SUBDOMAIN, ZENDESK_AGENT_EMAIL, ZENDESK_API_TOKEN. Do not hardcode. Configure reporting_window_daily, reporting_window_weekly, and reporting_window_monthly as environment variables specifying the lookback period in ISO 8601 duration format (e.g. P1D, P7D, P1M).
Key endpoints
GET /api/v2/search.json?query=type:ticket created>{start_date} (ticket list). GET /api/v2/tickets/{id}/satisfaction_ratings.json (CSAT per ticket). GET /api/v2/ticket_metrics.json (resolution and first-response times). Paginate using next_page cursor; do not assume all results fit in one response.
Rate limits
Zendesk Suite Team: 700 requests/minute per subdomain. At current volume (~280 runs/month, roughly 10 per day), peak usage is well below this ceiling. Throttling is not required at current volume, but the integration must respect Retry-After headers and implement exponential backoff if a 429 is received.
Constraints
API access is plan-gated; confirm the account is on Suite Team or above before build. The Search API returns a maximum of 1,000 results per query; if ticket volume per period exceeds 1,000, implement cursor-based pagination using the after_cursor parameter. CSAT ratings are only available if satisfaction surveys are enabled in the Zendesk account settings.
// Input
schedule_trigger: { cadence: 'daily' | 'weekly' | 'monthly', period_start: ISO8601, period_end: ISO8601 }
// Output
ticket_records: [ { ticket_id, created_at, resolved_at, first_response_at, status, assignee_id, tags, category, csat_score, sla_breached } ]
Google Sheets

Used by both the Data Fetch Agent (Agent 1) and the Reporting Agent (Agent 2). Agent 1 writes raw ticket records to a dedicated raw_data tab. Agent 2 reads that tab and writes calculated metric outputs to a metrics_summary tab.

Auth method
OAuth 2.0 via a Google service account. The service account JSON key is stored in the credential store (GSHEETS_SERVICE_ACCOUNT_JSON). The target spreadsheet must be shared with the service account email address with Editor permission.
Required scopes
https://www.googleapis.com/auth/spreadsheets (read and write to spreadsheet). https://www.googleapis.com/auth/drive.file (access files created by or shared with the service account).
Trigger setup
No webhook trigger on this tool. Sheets is written to by Agent 1 on schedule completion, and read by Agent 2 immediately after Agent 1 confirms success. Inter-agent handoff is managed by the orchestration layer, not a Sheets-native trigger.
Required configuration
Store in credential store: GSHEETS_SPREADSHEET_ID, GSHEETS_RAW_TAB_NAME (default: raw_data), GSHEETS_METRICS_TAB_NAME (default: metrics_summary). Do not hardcode spreadsheet IDs or tab names. The raw_data tab must have the exact column headers defined in Section 03 before the first run. If the spreadsheet is moved or renamed, the Looker Studio data source connection must be re-authorised manually.
Sheet structure
raw_data tab: row 1 is the header row (see Section 03 for exact column names). Data rows begin at row 2. Agent 1 clears rows 2 onwards and rewrites the full dataset on each run to avoid stale records. metrics_summary tab: fixed layout with one row per metric, columns: metric_name, current_value, prior_value, delta, period_label. Agent 2 overwrites values in place; the row structure must not change between runs.
Rate limits
Google Sheets API: 300 requests/minute per project and 60 requests/minute per user. Agent 1 batches all writes into a single batchUpdate call. Agent 2 performs one read and one write. At current volume, rate limits are not a concern. If ticket volume grows beyond 5,000 rows per period, consider chunking writes into batches of 500 rows.
Constraints
The spreadsheet must not be renamed or moved after Looker Studio is connected. Row 1 header names in raw_data must match exactly the field names defined in Section 03; any rename will break downstream metric formulas and the Looker Studio data source.
// Input (Agent 1 write)
ticket_records[]: array of ticket objects from Zendesk
target_tab: GSHEETS_RAW_TAB_NAME
// Output (Agent 1 write)
write_confirmation: { rows_written: integer, tab: string, timestamp: ISO8601 }
// Input (Agent 2 read)
source_tab: GSHEETS_RAW_TAB_NAME
// Output (Agent 2 write)
metrics_written: { tab: GSHEETS_METRICS_TAB_NAME, rows_updated: integer, period_label: string }
Integration and API SpecPage 1 of 4
FS-DOC-05Technical
Looker Studio

Used by the Reporting Agent (Agent 2) as the live visual dashboard layer. Looker Studio connects directly to the Google Sheets metrics_summary and raw_data tabs as its data source. The automation does not call the Looker Studio API directly; the dashboard refreshes automatically when the underlying Sheet is updated.

Auth method
OAuth 2.0 via the Google account that owns the Looker Studio report. The data source connection is authorised at setup time and persists as long as the Sheet is not moved or the sharing permissions on the service account are not revoked.
Required scopes
No API scopes required for the automation itself. The data source connection in Looker Studio uses the same service account or owner Google account that has Editor access to the spreadsheet.
Trigger setup
No webhook or API call. Looker Studio polls the connected Google Sheet on a refresh schedule configured inside the Looker Studio report settings. Set the data source refresh interval to Every 15 minutes to ensure the dashboard reflects the latest Agent 2 output within an acceptable window after each run.
Required configuration
Store in credential store: LOOKER_STUDIO_REPORT_URL (the shareable link to the live dashboard, used by Agent 3 to include in the email and Notion log). The data source connector must be set to the correct GSHEETS_SPREADSHEET_ID and the correct tab names. Do not rename tabs after the data source is connected.
Rate limits
Not applicable. Looker Studio is a consumer of the Google Sheets data source, not called programmatically by the automation. No throttling consideration applies at current volume.
Constraints
If the Google Sheet is renamed, moved to a different Drive folder, or the service account loses Editor access, the Looker Studio data source will break and must be re-authorised manually. Document this dependency in the SOP so the Support Manager is aware. The shareable report link must have Viewer access granted to all report recipients.
// Input
Google Sheets: metrics_summary tab (auto-polled by Looker Studio)
// Output
LOOKER_STUDIO_REPORT_URL: shareable link passed to Agent 3 payload
Gmail

Used by the Distribution Agent (Agent 3) to send the formatted report email to the manager distribution list after the Reporting Agent confirms the summary and commentary are ready.

Auth method
OAuth 2.0. The sending Google account authorises the automation with the gmail.send scope. The OAuth refresh token is stored in the credential store (GMAIL_OAUTH_REFRESH_TOKEN, GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET). Token refresh is handled automatically by the orchestration layer.
Required scopes
https://www.googleapis.com/auth/gmail.send (send email only; no read or modify access required or granted).
Trigger setup
No inbound webhook. Gmail is an action step only. Agent 3 calls the Gmail API POST /gmail/v1/users/me/messages/send with a pre-composed MIME message. The email is not triggered by an inbound Gmail event.
Required configuration
Store in credential store: GMAIL_SENDER_ADDRESS, GMAIL_DISTRIBUTION_LIST (comma-separated recipient addresses), GMAIL_SUBJECT_TEMPLATE (e.g. 'Support Report: {{period_label}}'), GMAIL_BODY_TEMPLATE_ID (reference to the HTML email template stored in the orchestration layer, not hardcoded inline). The email body template must include placeholders: {{period_label}}, {{summary_commentary}}, {{csat_score}}, {{ticket_volume}}, {{sla_breach_count}}, {{looker_studio_url}}.
Rate limits
Gmail API: 250 quota units per user per second; sending one email per report run consumes 100 units. At 280 runs/month, this is negligible. No throttling required.
Constraints
The sending account must have the Gmail API enabled in the associated Google Cloud project. If the sending account is a Google Workspace account, the Workspace administrator may need to grant the OAuth client domain-wide delegation or approve the app in the admin console. Attachments are not used in this integration; the email links to the Looker Studio dashboard rather than attaching a PDF.
// Input
agent_3_payload: { period_label, summary_commentary, csat_score, ticket_volume, sla_breach_count, looker_studio_url }
// Output
gmail_send_result: { message_id: string, thread_id: string, status: 'sent' | 'error' }
Slack

Used by the Distribution Agent (Agent 3) to post a formatted headline summary to the designated support Slack channel immediately after the Gmail send step completes.

Auth method
OAuth 2.0 Bot token. A Slack app is created in the workspace, granted the required bot scopes, installed to the workspace, and the resulting Bot User OAuth Token is stored in the credential store (SLACK_BOT_TOKEN). The bot must be added to the target channel.
Required scopes
chat:write (post messages to channels the bot is a member of). channels:read (confirm the target channel ID at setup time). No additional scopes required.
Webhook/trigger setup
No inbound webhook. Slack is an outbound action only. The automation calls the Slack Web API POST https://slack.com/api/chat.postMessage with the target channel ID and a Block Kit formatted message payload. Signature validation is not required for outbound-only integrations.
Required configuration
Store in credential store: SLACK_BOT_TOKEN, SLACK_CHANNEL_ID (the channel ID, not the channel name, to prevent breakage if the channel is renamed). SLACK_MESSAGE_TEMPLATE must define the Block Kit JSON structure with placeholders: {{period_label}}, {{csat_score}}, {{ticket_volume}}, {{sla_breach_count}}, {{first_response_time_avg}}, {{looker_studio_url}}. Template is stored in the orchestration layer, not hardcoded in the workflow step.
Rate limits
Slack Web API: Tier 3 method (chat.postMessage) allows approximately 1 request/second. At current volume, one post per report run, this limit is never approached. No throttling required.
Constraints
The Slack bot must be a member of SLACK_CHANNEL_ID before the first run. If the channel is archived or the bot is removed, the integration will fail silently unless error handling is configured (see Section 05). Channel IDs are preferred over channel names because names can change without breaking the stored credential.
// Input
agent_3_payload: { period_label, csat_score, ticket_volume, sla_breach_count, first_response_time_avg, looker_studio_url }
// Output
slack_post_result: { ok: boolean, ts: string, channel: string } | { ok: false, error: string }
Notion

Used by the Distribution Agent (Agent 3) to append a new row to the team's persistent reporting log database in Notion. Each entry records the report date, period covered, headline metrics, and a link to the live dashboard.

Auth method
OAuth 2.0 internal integration token. A Notion integration is created at notion.so/my-integrations, the resulting integration secret token is stored in the credential store (NOTION_INTEGRATION_TOKEN). The target Notion database must be shared with the integration by the Notion workspace owner.
Required scopes
insert content (append new database rows). read content (verify the target database exists and retrieve its schema at setup time). No update or delete permissions are required or granted.
Trigger setup
No webhook. Notion is an outbound action only. The automation calls POST https://api.notion.com/v1/pages with a parent database_id and a properties object matching the target database schema.
Required configuration
Store in credential store: NOTION_INTEGRATION_TOKEN, NOTION_DATABASE_ID (the UUID of the reporting log database, not the page URL, and not hardcoded). The target Notion database must have the following property columns matching the exact types: Report Date (date), Period Covered (rich_text), Cadence (select: daily/weekly/monthly), CSAT Score (number), Ticket Volume (number), SLA Breaches (number), First Response Avg (rich_text), Dashboard Link (url). Column names must not change after setup.
Rate limits
Notion API: 3 requests/second average. At one append per report run and 280 runs/month, peak load is one request per run. No throttling required at current volume.
Constraints
The Notion integration token must be re-added if the workspace is transferred or if the integration is revoked by a workspace admin. Property column types in the target database must not be changed after setup; a type mismatch causes the API call to return a 400 error. The NOTION_DATABASE_ID must be stored as the raw UUID (e.g. 1a2b3c4d-5e6f-7890-abcd-ef1234567890), not as a URL slug.
// Input
agent_3_payload: { report_date: ISO8601, period_label: string, cadence: 'daily'|'weekly'|'monthly', csat_score: number, ticket_volume: integer, sla_breach_count: integer, first_response_avg: string, looker_studio_url: string }
// Output
notion_create_result: { object: 'page', id: string, url: string } | { status: 400|401|404, message: string }
Integration and API SpecPage 2 of 4
FS-DOC-05Technical

03Field mappings between tools

The tables below define every field-level mapping across the three agent handoffs. Source and destination field names are exact; any deviation from these names will break downstream steps. All field names are case-sensitive.

Handoff 1: Zendesk API response to Google Sheets raw_data tab (Data Fetch Agent, Agent 1)

Source tool
Source field
Destination tool
Destination field
Zendesk
id
Google Sheets
ticket_id
Zendesk
created_at
Google Sheets
created_at
Zendesk
updated_at
Google Sheets
updated_at
Zendesk
solved_at (via ticket_metric)
Google Sheets
resolved_at
Zendesk
reply_time_in_minutes.business (ticket_metric)
Google Sheets
first_response_minutes
Zendesk
full_resolution_time_in_minutes.business (ticket_metric)
Google Sheets
resolution_minutes
Zendesk
status
Google Sheets
status
Zendesk
assignee_id
Google Sheets
assignee_id
Zendesk
tags[]
Google Sheets
tags
Zendesk
custom_field: cf_category
Google Sheets
category
Zendesk
satisfaction_rating.score
Google Sheets
csat_score
Zendesk
sla_policy.breached
Google Sheets
sla_breached

Handoff 2: Google Sheets metrics_summary tab to Agent 3 distribution payload (Reporting Agent, Agent 2 to Distribution Agent, Agent 3)

Source tool
Source field
Destination tool
Destination field
Google Sheets
metrics_summary.current_value WHERE metric_name='csat_avg'
Agent 3 payload
csat_score
Google Sheets
metrics_summary.current_value WHERE metric_name='ticket_volume'
Agent 3 payload
ticket_volume
Google Sheets
metrics_summary.current_value WHERE metric_name='sla_breach_count'
Agent 3 payload
sla_breach_count
Google Sheets
metrics_summary.current_value WHERE metric_name='first_response_avg_minutes'
Agent 3 payload
first_response_time_avg
Google Sheets
metrics_summary.current_value WHERE metric_name='resolution_avg_minutes'
Agent 3 payload
resolution_time_avg
Google Sheets
metrics_summary.period_label
Agent 3 payload
period_label
Google Sheets
metrics_summary.commentary_text (AI-generated)
Agent 3 payload
summary_commentary
Looker Studio
LOOKER_STUDIO_REPORT_URL (from credential store)
Agent 3 payload
looker_studio_url

Handoff 3: Agent 3 payload to Gmail, Slack, and Notion (Distribution Agent, Agent 3)

Source tool
Source field
Destination tool
Destination field
Agent 3 payload
period_label
Gmail
Subject: {{period_label}} in GMAIL_SUBJECT_TEMPLATE
Agent 3 payload
summary_commentary
Gmail
Body: {{summary_commentary}}
Agent 3 payload
csat_score
Gmail
Body: {{csat_score}}
Agent 3 payload
ticket_volume
Gmail
Body: {{ticket_volume}}
Agent 3 payload
sla_breach_count
Gmail
Body: {{sla_breach_count}}
Agent 3 payload
looker_studio_url
Gmail
Body: {{looker_studio_url}}
Agent 3 payload
period_label
Slack
Block Kit text: {{period_label}}
Agent 3 payload
csat_score
Slack
Block Kit field: {{csat_score}}
Agent 3 payload
ticket_volume
Slack
Block Kit field: {{ticket_volume}}
Agent 3 payload
sla_breach_count
Slack
Block Kit field: {{sla_breach_count}}
Agent 3 payload
first_response_time_avg
Slack
Block Kit field: {{first_response_time_avg}}
Agent 3 payload
looker_studio_url
Slack
Block Kit action url: {{looker_studio_url}}
Agent 3 payload
report_date
Notion
Report Date (date property)
Agent 3 payload
period_label
Notion
Period Covered (rich_text property)
Agent 3 payload
cadence
Notion
Cadence (select property)
Agent 3 payload
csat_score
Notion
CSAT Score (number property)
Agent 3 payload
ticket_volume
Notion
Ticket Volume (number property)
Agent 3 payload
sla_breach_count
Notion
SLA Breaches (number property)
Agent 3 payload
first_response_time_avg
Notion
First Response Avg (rich_text property)
Agent 3 payload
looker_studio_url
Notion
Dashboard Link (url property)

04Build stack and orchestration

Orchestration layout
Three discrete workflows, one per agent (Data Fetch Agent, Reporting Agent, Distribution Agent). Each workflow is a self-contained unit in the automation platform. Inter-agent handoffs are event-driven: Agent 1 emits a success event that triggers Agent 2; Agent 2 emits a success event that triggers Agent 3. All three workflows share a single centralised credential store so secrets are never duplicated across workflows.
Agent 1 trigger mechanism
Scheduled poll. The orchestration layer fires Agent 1 on three independent cron-style schedules: daily at 07:00 (account timezone), weekly on Monday at 08:00, and monthly on the 1st at 08:00. No inbound webhook. Cadence is passed as a runtime variable (cadence: 'daily' | 'weekly' | 'monthly') so a single workflow handles all three report types with conditional period-window logic.
Agent 2 trigger mechanism
Event-driven, no poll. Agent 2 is triggered by the success completion event emitted by Agent 1 upon confirming the Google Sheets write_confirmation. The trigger payload carries cadence, period_start, period_end, and write_confirmation metadata. No signature validation is required as the trigger is internal to the orchestration platform.
Agent 3 trigger mechanism
Event-driven, no poll. Agent 3 is triggered by the success completion event emitted by Agent 2. For monthly cadence runs, Agent 2 pauses at the commentary-ready state and emits a pending_review event instead of a success event; Agent 3 remains dormant until the Support Manager approves the commentary, which triggers a manual-approval-complete event and resumes the Agent 3 workflow. Approval is logged with a timestamp in the orchestration run history.
Credential store type
Platform-native encrypted credential store (environment variable vault). All secrets are referenced by key name in workflow steps; plaintext values are never written into workflow logic, step configurations, or logs.
Monthly human review gate
When cadence='monthly', Agent 2 writes the draft commentary to a designated Google Sheets cell (metrics_summary tab, cell B_commentary_draft) and sends an internal platform notification to the Support Manager review step. The workflow is suspended until the approval action is completed. Maximum wait time before escalation alert: 4 hours.
Credential store contents — store all values in the platform-native encrypted vault; never commit to source control or workflow configuration files
// Credential store — all keys required before first run

// Zendesk (Agent 1)
ZENDESK_SUBDOMAIN            = 'yourcompany'          // no .zendesk.com suffix
ZENDESK_AGENT_EMAIL          = 'automation@yourcompany.com'
ZENDESK_API_TOKEN            = '<generated in Zendesk Admin>'

// Google Sheets (Agents 1 and 2)
GSHEETS_SERVICE_ACCOUNT_JSON = '<full JSON key object for service account>'
GSHEETS_SPREADSHEET_ID       = '<26-char Google Sheets ID from URL>'
GSHEETS_RAW_TAB_NAME         = 'raw_data'
GSHEETS_METRICS_TAB_NAME     = 'metrics_summary'

// Looker Studio (Agent 2 output, Agent 3 input)
LOOKER_STUDIO_REPORT_URL     = 'https://lookerstudio.google.com/reporting/<report-id>'

// Gmail (Agent 3)
GMAIL_CLIENT_ID              = '<OAuth 2.0 client ID from Google Cloud Console>'
GMAIL_CLIENT_SECRET          = '<OAuth 2.0 client secret>'
GMAIL_OAUTH_REFRESH_TOKEN    = '<long-lived refresh token from OAuth flow>'
GMAIL_SENDER_ADDRESS         = 'reports@yourcompany.com'
GMAIL_DISTRIBUTION_LIST      = 'manager1@yourcompany.com,manager2@yourcompany.com'
GMAIL_SUBJECT_TEMPLATE       = 'Support Report: {{period_label}}'
GMAIL_BODY_TEMPLATE_ID       = 'email_template_v1'   // references template in orchestration layer

// Slack (Agent 3)
SLACK_BOT_TOKEN              = 'xoxb-<workspace-bot-token>'
SLACK_CHANNEL_ID             = 'C0XXXXXXXXX'          // channel ID, not name

// Notion (Agent 3)
NOTION_INTEGRATION_TOKEN     = 'secret_<integration-token>'
NOTION_DATABASE_ID           = '<UUID of reporting log database>'
Integration and API SpecPage 3 of 4
FS-DOC-05Technical

05Error handling and retry logic

Unhandled exceptions must never fail silently. Every integration point in this pipeline has a defined failure behaviour. If an error scenario is not covered by the table below, the default behaviour is: log the full error payload to the platform run history, send an alert to support@gofullspec.com and the configured process owner, and halt the current run without retrying indefinitely.
Integration
Scenario
Required behaviour
Zendesk API
401 Unauthorized (invalid or expired API token)
Halt Agent 1 immediately. Do not retry. Send alert to process owner with run ID and error detail. Log to platform run history. Manual credential refresh required before next run.
Zendesk API
429 Too Many Requests (rate limit hit)
Respect the Retry-After header value. Pause and retry the same request after the specified delay. If three consecutive 429 responses are received, halt the run and alert the process owner.
Zendesk API
500 or 503 Server Error (Zendesk outage)
Retry with exponential backoff: wait 30 seconds, then 2 minutes, then 5 minutes. After three failed attempts, halt Agent 1, skip the current run, and log a missed-run entry to Google Sheets (metrics_summary tab, cell B_run_status: 'missed — Zendesk unavailable'). Alert process owner.
Zendesk API
Empty result set (no tickets in period)
Do not treat as an error. Write zero-value records to raw_data tab and proceed with metric calculation. The metrics_summary tab must reflect zero values accurately; do not carry forward prior period values.
Google Sheets
403 Forbidden (service account lacks Editor permission)
Halt Agent 1 immediately. Do not retry. Alert process owner with spreadsheet ID and service account email. Manual permission grant required.
Google Sheets
Write timeout or connection failure during batch write
Retry the full batchUpdate call up to three times with a 15-second delay between attempts. If all three fail, halt the current run and alert. Do not write a partial dataset; always overwrite the full tab or not at all.
Google Sheets
Header row mismatch detected on raw_data tab (schema drift)
Halt immediately. Do not overwrite data. Alert process owner and FullSpec team at support@gofullspec.com with the detected column list vs expected column list. This is a breaking configuration change.
Gmail
OAuth token expired or refresh fails
Attempt one automatic token refresh using GMAIL_OAUTH_REFRESH_TOKEN. If refresh fails, halt Agent 3 email step, log error, and alert process owner. Report metrics are still written to Notion and Slack if those steps succeed independently.
Gmail
Email delivery failure (bounce or API error)
Log the error and message_id attempt to the platform run history. Retry once after 60 seconds. If second attempt fails, alert process owner with the error detail. Do not suppress the failure.
Slack
channel_not_found or not_in_channel error
Halt the Slack step only. Do not halt Gmail or Notion steps. Log the error. Alert process owner: the bot may have been removed from the channel. Manual re-addition required. Post a fallback alert to the process owner via Gmail.
Slack
Slack API timeout or 500 error
Retry once after 30 seconds. If the retry fails, skip the Slack step for this run, log the failure, and alert the process owner. The run is considered partially successful; Gmail and Notion steps proceed.
Notion
400 Bad Request (property type mismatch or missing property)
Halt the Notion step only. Log the full API response body. Alert process owner and FullSpec team at support@gofullspec.com. This indicates a schema change in the Notion database. Do not retry until the schema is confirmed and corrected.
Notion
401 Unauthorized (integration token revoked)
Halt the Notion step only. Alert process owner. Do not retry. Manual token re-generation and credential store update required before the next run.
Monthly review gate
Support Manager does not approve commentary within 4 hours
Escalate: send a reminder notification to the Support Manager and a secondary alert to the process owner. If no approval is received within 8 hours of the original pending_review event, halt the monthly run and log it as 'pending — awaiting manual approval'. Do not auto-approve or auto-distribute without human sign-off.
Integration and API SpecPage 4 of 4

More documents for this process

Every document generated for Support Reporting & Insights.

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