Back to SLA Monitoring & Breach Alerting

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

SLA Monitoring and Breach Alerting

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

This document is the authoritative integration reference for the SLA Monitoring and Breach Alerting automation. It covers every tool connected to the workflow, the exact credentials and scopes required, field mappings between systems, the orchestration layout, and the defined failure behaviour for every integration point. The FullSpec team uses this specification to build, configure, and validate all connections. Your team does not need to interact with these APIs directly, but this document should be stored alongside the credential store and updated whenever a connected tool changes its configuration.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent
Automation platform
Orchestration layer: schedules the 15-min poll, routes data between agents, manages credentials and retries
N/A (internal)
Platform-dependent; must support scheduled triggers and credential stores
Both agents
Zendesk
Ticket source for SLA Monitor Agent; audit note target for Alert Dispatch Agent
API token (Basic auth over HTTPS)
Suite Team or above (API access required)
Agent 1, Agent 2
HubSpot
SLA tier lookup per client; breach activity record logging
Private App access token (OAuth 2.0 optional)
Starter CRM or above (API access included)
Agent 1, Agent 2
Slack
Sends graded warning alerts to assigned agents at 75% SLA threshold
Bot OAuth token (Slack App)
Free tier sufficient; Pro recommended for audit log retention
Agent 2
PagerDuty
Critical escalation and on-call routing at 95% SLA threshold
Events API v2 integration key (REST API key for management calls)
Professional plan (escalation policies required)
Agent 2
Gmail
Delivers formatted weekly SLA summary email to support manager every Monday
OAuth 2.0 (Google service account or delegated user credentials)
Google Workspace Business Starter or personal Gmail with OAuth consent
Agent 2
Before you connect anything: all integrations must be validated against sandbox or staging instances before production credentials are entered into the credential store. For Zendesk, use a dedicated sandbox environment. For HubSpot, use a developer test account. For PagerDuty, use a test service with a separate integration key. For Slack, use a non-production workspace or a dedicated #automation-testing channel. For Gmail, use a test Google Workspace account. Never run connection tests against live production data.
Integration and API SpecPage 1 of 4
FS-DOC-05Technical

02Per-tool integration detail

Zendesk

Zendesk is polled every 15 minutes by the SLA Monitor Agent to retrieve all open tickets. The Alert Dispatch Agent writes internal notes back to individual tickets as an audit trail. Both directions use the Zendesk REST API v2.

Auth method
API token via Basic auth: credentials formatted as {email_address}/token:{api_token} encoded in Base64. Token is stored in the credential store as ZENDESK_API_TOKEN. Subdomain stored as ZENDESK_SUBDOMAIN.
Required scopes
tickets:read, tickets:write, users:read. Generated under Admin > Apps and Integrations > Zendesk API > API token. OAuth scope equivalent: read write (if OAuth app is used instead of token auth).
Webhook / trigger setup
No inbound webhook required. The automation platform initiates outbound HTTP GET requests to the Zendesk API on a 15-minute schedule. No Zendesk trigger or webhook needs to be created in the Zendesk admin panel.
Required configuration
The Zendesk ticket object must carry a custom field or organisation field that stores the HubSpot client identifier (see field mappings). Field ID for this custom field must be stored as ZENDESK_CLIENT_ID_FIELD_ID in the credential store, not hardcoded. The internal note author must be a dedicated API user account, not a named agent account.
Rate limits
Zendesk REST API v2: 700 requests/minute on Suite Team and above. At current volume (~200 tickets/week, polled every 15 minutes) the automation issues at most 1 list request plus up to 200 individual note-write requests per cycle, averaging well under 20 requests/minute. Throttling is not required at current volume but must be implemented if ticket volume exceeds 5,000 open tickets per poll cycle.
Constraints
API tokens do not expire but must be rotated if staff with token access leave the organisation. The API does not natively return business-hours-adjusted SLA time remaining; this calculation is performed by the automation layer using raw creation timestamps and business-hours configuration. Internal notes posted via API are not visible to end-users but are visible to all agents.
// Poll request
GET https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2/tickets.json?status=open&per_page=100&page={n}
Authorization: Basic {Base64(email/token:ZENDESK_API_TOKEN)}

// Ticket object fields consumed
ticket.id, ticket.created_at, ticket.updated_at, ticket.status,
ticket.assignee_id, ticket.custom_fields[ZENDESK_CLIENT_ID_FIELD_ID]

// Note write request
PUT https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2/tickets/{ticket_id}.json
Body: { ticket: { comment: { body: '{note_text}', public: false } } }
HubSpot

The SLA Monitor Agent queries HubSpot to retrieve the contracted SLA tier, response window, and resolution window for each ticket's client. The Alert Dispatch Agent writes breach activity records back to the HubSpot client record when a breach occurs.

Auth method
Private App access token. Token stored in credential store as HUBSPOT_ACCESS_TOKEN. No OAuth redirect flow required for server-to-server calls. Token must be regenerated if the HubSpot Private App is deleted or reset.
Required scopes
crm.objects.contacts.read, crm.objects.companies.read, crm.objects.companies.write, crm.objects.custom.read, crm.objects.custom.write, timeline.write (for activity record creation). Scopes are selected during Private App creation in HubSpot > Settings > Integrations > Private Apps.
Webhook / trigger setup
No inbound webhook required. The automation platform makes outbound GET requests to HubSpot on each poll cycle. No HubSpot workflow or webhook subscription is needed.
Required configuration
Each HubSpot company record must carry a custom property storing the SLA tier label (e.g. sla_tier: 'gold', 'silver', 'bronze'). The internal property name must be stored as HUBSPOT_SLA_TIER_PROPERTY in the credential store. The HubSpot company ID or a unique identifier must match the client identifier stored on the Zendesk ticket custom field. The breach activity record target object type ID must be stored as HUBSPOT_BREACH_OBJECT_TYPE_ID.
Rate limits
HubSpot CRM API: 100 requests/10 seconds and 250,000 requests/day on Starter and above. At current volume the automation issues at most 200 company lookup requests per 15-minute cycle, well within limits. Throttling is not required at current volume.
Constraints
Lookups fail silently if the Zendesk client identifier does not match any HubSpot company record. The automation must catch null responses on sla_tier and route those tickets to a manual review queue rather than proceeding with a default tier assumption. Write operations require the access token to have company write scope; read-only tokens will fail on breach logging.
// SLA tier lookup
GET https://api.hubapi.com/crm/v3/objects/companies/{company_id}
  ?properties=sla_tier,sla_response_hours,sla_resolution_hours,hs_object_id
Authorization: Bearer {HUBSPOT_ACCESS_TOKEN}

// Breach activity record creation
POST https://api.hubapi.com/crm/v3/objects/{HUBSPOT_BREACH_OBJECT_TYPE_ID}
Authorization: Bearer {HUBSPOT_ACCESS_TOKEN}
Body: {
  properties: {
    zendesk_ticket_id: '{ticket_id}',
    sla_tier: '{sla_tier}',
    minutes_overrun: {minutes_overrun},
    breach_timestamp: '{iso8601_timestamp}'
  },
  associations: [{ to: { id: '{company_id}' }, types: [{ category: 'HUBSPOT_DEFINED', typeId: 1 }] }]
}
Slack

The Alert Dispatch Agent sends structured warning messages to the Slack channel or direct message thread of the assigned agent when a ticket crosses the 75% SLA threshold. Slack is an outbound-only integration; no events or webhooks are consumed from Slack.

Auth method
Slack Bot OAuth token. Token stored in credential store as SLACK_BOT_TOKEN. The Slack App must be installed to the workspace and granted the required scopes via the App's OAuth and Permissions settings page.
Required scopes
chat:write (send messages as the bot), users:read.email (resolve agent email to Slack user ID), im:write (open DM channels). If posting to a channel: channels:read to verify channel membership.
Webhook / trigger setup
Incoming webhook URL may be used as a simpler alternative to the bot token for posting only. If using an incoming webhook, store the URL as SLACK_WEBHOOK_URL and no bot token is required. The incoming webhook approach does not support user lookup; bot token approach is preferred for agent-targeted DMs.
Required configuration
The Slack channel ID for the #sla-alerts fallback channel must be stored as SLACK_ALERT_CHANNEL_ID. Agent Zendesk email addresses must match their Slack workspace email addresses for user ID resolution. The Slack App must be approved by the workspace admin before deployment.
Rate limits
Slack Web API: 1 request/second per method (Tier 3 for chat.postMessage). At current volume the automation sends at most ~200 messages per poll cycle, taking under 4 minutes to deliver if sequential. Rate limiting with 1-second delays between messages is required if sending more than 20 messages in a single cycle to avoid Tier 3 throttling errors.
Constraints
Slack DM delivery fails if the agent's Slack account is deactivated. The automation must fall back to posting to SLACK_ALERT_CHANNEL_ID with the agent's name mentioned in the message text. Messages are not retried by Slack if delivery fails at the application layer; retry logic must be implemented in the orchestration layer.
// Send agent warning DM
POST https://slack.com/api/chat.postMessage
Authorization: Bearer {SLACK_BOT_TOKEN}
Body: {
  channel: '{resolved_agent_slack_user_id}',
  text: 'SLA Warning: Ticket #{ticket_id} ({client_name}) is at {pct_elapsed}% of its {sla_tier} window. {minutes_remaining} minutes remaining.',
  blocks: [ ... structured Block Kit payload ... ]
}
PagerDuty

The Alert Dispatch Agent fires a PagerDuty incident when a ticket crosses 95% of its SLA window without a resolution or status update. PagerDuty routes the incident to the on-call support manager according to the configured escalation policy.

Auth method
Events API v2 uses an integration key (routing key), not a user API token. The integration key is stored as PAGERDUTY_INTEGRATION_KEY. REST API key (stored as PAGERDUTY_API_KEY) is required only for management operations such as listing on-call schedules or updating services.
Required scopes
Events API v2 requires no OAuth scopes; the integration key is tied to a specific PagerDuty service. REST API key type: read-only for schedule queries; full-access key is not required for this automation.
Webhook / trigger setup
No inbound webhook from PagerDuty is consumed by this automation. PagerDuty's own escalation policy handles on-call routing and acknowledgement notifications natively. If a future enhancement requires acknowledgement callbacks, a PagerDuty webhook subscription to the automation platform's inbound endpoint would be required.
Required configuration
A dedicated PagerDuty service named 'SLA Breach Escalation' must be created before go-live. The service's escalation policy must reference the correct on-call schedule for the support manager role. The service integration key is stored as PAGERDUTY_INTEGRATION_KEY. The dedup_key field in each incident payload must be set to the Zendesk ticket ID to prevent duplicate incidents for the same ticket across poll cycles.
Rate limits
PagerDuty Events API v2: no hard per-minute rate limit documented for Professional plans; practical throttle is approximately 120 events/minute. At current volume (at most a handful of 95% threshold breaches per cycle) no throttling is needed.
Constraints
If the on-call schedule has no coverage (e.g. no one is on call), PagerDuty will not deliver the alert and will mark the incident as unacknowledged. An escalation policy timeout must be configured so that incidents escalate to a secondary contact after 10 minutes without acknowledgement. The dedup_key mechanism means a second alert for the same ticket within the same incident lifecycle will update the existing incident rather than create a duplicate.
// Fire PagerDuty incident
POST https://events.pagerduty.com/v2/enqueue
Content-Type: application/json
Body: {
  routing_key: '{PAGERDUTY_INTEGRATION_KEY}',
  event_action: 'trigger',
  dedup_key: 'zendesk-{ticket_id}',
  payload: {
    summary: 'SLA Critical: Ticket #{ticket_id} ({client_name}) at {pct_elapsed}% of {sla_tier} window',
    severity: 'critical',
    source: 'SLA Monitor Automation',
    custom_details: {
      ticket_id: '{ticket_id}',
      sla_tier: '{sla_tier}',
      minutes_remaining: {minutes_remaining},
      assigned_agent: '{agent_email}'
    }
  }
}
Gmail

The Alert Dispatch Agent sends a formatted weekly SLA summary email to the support manager every Monday morning. This is an outbound-only integration using the Gmail API via OAuth 2.0.

Auth method
OAuth 2.0. A Google Cloud project must be created with the Gmail API enabled. A service account with domain-wide delegation is recommended for server-to-server sending without user interaction. Alternatively, a delegated user credential (refresh token) is acceptable. Refresh token stored as GMAIL_REFRESH_TOKEN; client ID as GMAIL_CLIENT_ID; client secret as GMAIL_CLIENT_SECRET.
Required scopes
https://www.googleapis.com/auth/gmail.send (send-only; does not grant read access to mailbox). If using a service account with domain-wide delegation, the scope must be granted in Google Workspace Admin > Security > API Controls > Domain-wide Delegation.
Webhook / trigger setup
No inbound webhook. The Monday morning send is triggered by a scheduled event in the orchestration layer (cron: 0 8 * * 1 in the target timezone). The automation compiles the prior week's breach and near-breach data accumulated in the workflow's internal data store before composing the email.
Required configuration
The recipient email address for the support manager must be stored as GMAIL_SUMMARY_RECIPIENT. The sender address must be stored as GMAIL_SENDER_ADDRESS and must match the account for which OAuth credentials were generated. The email subject template and HTML body template are stored as configuration variables, not hardcoded in the workflow steps.
Rate limits
Gmail API sending quota: 250 quota units per user per second; each send costs 100 units, allowing 2-3 sends per second. Daily sending limit: 500 messages per day for standard Gmail; 2,000 per day for Google Workspace. Sending one message per week is well within all limits. No throttling required.
Constraints
OAuth refresh tokens expire if unused for 6 months or if the user revokes access. The credential store must be checked quarterly to confirm token validity. If the token is invalid, the weekly email will fail silently unless the error handling layer catches the 401 response and routes an alert to support@gofullspec.com.
// Token refresh before send
POST https://oauth2.googleapis.com/token
Body: { client_id: GMAIL_CLIENT_ID, client_secret: GMAIL_CLIENT_SECRET,
        refresh_token: GMAIL_REFRESH_TOKEN, grant_type: 'refresh_token' }

// Send weekly summary
POST https://gmail.googleapis.com/gmail/v1/users/{GMAIL_SENDER_ADDRESS}/messages/send
Authorization: Bearer {access_token}
Body: { raw: '{Base64URL_encoded_MIME_message}' }

// MIME message includes:
// To: {GMAIL_SUMMARY_RECIPIENT}
// Subject: Weekly SLA Report - w/e {date}
// Content-Type: text/html
// Body: rendered HTML summary of breach_log[] accumulated since last Monday
Integration and API SpecPage 2 of 4
FS-DOC-05Technical

03Field mappings between tools

The tables below define the exact field mappings for each agent handoff in the automation. Use these as the authoritative reference when configuring data transformation steps in the orchestration layer. All field names are shown in their native API format.

Handoff 1: Zendesk poll to SLA Monitor Agent (ticket ingestion)

Source tool
Source field
Destination tool
Destination field
Zendesk
`ticket.id`
SLA Monitor Agent (internal)
`ticket_id`
Zendesk
`ticket.created_at`
SLA Monitor Agent (internal)
`created_at_iso`
Zendesk
`ticket.updated_at`
SLA Monitor Agent (internal)
`last_updated_at_iso`
Zendesk
`ticket.status`
SLA Monitor Agent (internal)
`ticket_status`
Zendesk
`ticket.assignee_id`
SLA Monitor Agent (internal)
`zendesk_assignee_id`
Zendesk
`ticket.custom_fields[ZENDESK_CLIENT_ID_FIELD_ID].value`
SLA Monitor Agent (internal)
`hubspot_company_id`

Handoff 2: SLA Monitor Agent to HubSpot (SLA tier lookup)

Source tool
Source field
Destination tool
Destination field
SLA Monitor Agent (internal)
`hubspot_company_id`
HubSpot
`/crm/v3/objects/companies/{id}` path param
HubSpot
`properties.sla_tier`
SLA Monitor Agent (internal)
`sla_tier_label`
HubSpot
`properties.sla_response_hours`
SLA Monitor Agent (internal)
`sla_response_hours`
HubSpot
`properties.sla_resolution_hours`
SLA Monitor Agent (internal)
`sla_resolution_hours`
HubSpot
`properties.hs_object_id`
SLA Monitor Agent (internal)
`hubspot_company_id_confirmed`

Handoff 3: SLA Monitor Agent classified output to Alert Dispatch Agent

Source tool
Source field
Destination tool
Destination field
SLA Monitor Agent (internal)
`ticket_id`
Alert Dispatch Agent (internal)
`ticket_id`
SLA Monitor Agent (internal)
`hubspot_company_id`
Alert Dispatch Agent (internal)
`hubspot_company_id`
SLA Monitor Agent (internal)
`sla_tier_label`
Alert Dispatch Agent (internal)
`sla_tier`
SLA Monitor Agent (internal)
`pct_elapsed`
Alert Dispatch Agent (internal)
`pct_elapsed`
SLA Monitor Agent (internal)
`minutes_remaining`
Alert Dispatch Agent (internal)
`minutes_remaining`
SLA Monitor Agent (internal)
`urgency_flag`
Alert Dispatch Agent (internal)
`urgency_flag`
SLA Monitor Agent (internal)
`zendesk_assignee_id`
Alert Dispatch Agent (internal)
`zendesk_assignee_id`
SLA Monitor Agent (internal)
`client_name`
Alert Dispatch Agent (internal)
`client_name`

Handoff 4: Alert Dispatch Agent to Zendesk (internal note write)

Source tool
Source field
Destination tool
Destination field
Alert Dispatch Agent (internal)
`ticket_id`
Zendesk
`/api/v2/tickets/{id}` path param
Alert Dispatch Agent (internal)
`note_body`
Zendesk
`ticket.comment.body`
Alert Dispatch Agent (internal)
`note_public_flag`
Zendesk
`ticket.comment.public` (always false)
Alert Dispatch Agent (internal)
`alert_sent_at_iso`
Zendesk
Embedded in `ticket.comment.body` text

Handoff 5: Alert Dispatch Agent to HubSpot (breach record logging)

Source tool
Source field
Destination tool
Destination field
Alert Dispatch Agent (internal)
`ticket_id`
HubSpot
`properties.zendesk_ticket_id`
Alert Dispatch Agent (internal)
`sla_tier`
HubSpot
`properties.sla_tier`
Alert Dispatch Agent (internal)
`minutes_overrun`
HubSpot
`properties.minutes_overrun`
Alert Dispatch Agent (internal)
`breach_timestamp_iso`
HubSpot
`properties.breach_timestamp`
Alert Dispatch Agent (internal)
`hubspot_company_id`
HubSpot
`associations[].to.id`

Handoff 6: Alert Dispatch Agent to PagerDuty (critical escalation)

Source tool
Source field
Destination tool
Destination field
Alert Dispatch Agent (internal)
`ticket_id`
PagerDuty
`dedup_key` (formatted as `zendesk-{ticket_id}`)
Alert Dispatch Agent (internal)
`client_name`
PagerDuty
`payload.summary` (embedded in string)
Alert Dispatch Agent (internal)
`sla_tier`
PagerDuty
`payload.custom_details.sla_tier`
Alert Dispatch Agent (internal)
`pct_elapsed`
PagerDuty
`payload.custom_details.pct_elapsed`
Alert Dispatch Agent (internal)
`minutes_remaining`
PagerDuty
`payload.custom_details.minutes_remaining`
Alert Dispatch Agent (internal)
`agent_email`
PagerDuty
`payload.custom_details.assigned_agent`
Integration and API SpecPage 3 of 4
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Two discrete workflows in the automation platform: one per agent. Workflow 1 (SLA Monitor Agent) handles the scheduled Zendesk poll, HubSpot lookup, and business-hours classification. Its output payload is passed directly to Workflow 2 (Alert Dispatch Agent) via an internal trigger or message queue. Both workflows share a single credential store; no credentials are duplicated across workflows.
Agent 1 trigger mechanism
Scheduled poll. Workflow 1 fires every 15 minutes via a cron-style schedule (*/15 * * * *) in the automation platform's scheduler. No inbound webhook is used. The scheduler must be configured to the organisation's primary timezone and must account for daylight saving transitions.
Agent 2 trigger mechanism
Internal event trigger. Workflow 2 is triggered by the completion event of Workflow 1, receiving the classified ticket list as its input payload. No external webhook is exposed. If Workflow 1 produces an empty classified list (all tickets safe), Workflow 2 still executes but skips all dispatch steps and records a 'no action' log entry.
Signature validation
No inbound webhooks from external systems are consumed in this automation, so inbound signature validation is not applicable at initial build. If PagerDuty acknowledgement callbacks are added in a future iteration, HMAC-SHA256 signature validation using the PagerDuty webhook secret must be implemented before that endpoint is exposed.
Credential store
All secrets are stored in the automation platform's native encrypted credential store. See code block below for the complete list of required credential entries.
Business-hours calculation
Business-hours logic is implemented as a reusable function module within Workflow 1. It reads SLA tier, client timezone (fetched from HubSpot property client_timezone), and a configurable business-hours calendar object stored as a JSON configuration variable BUSINESS_HOURS_CONFIG. This variable is not hardcoded; it is loaded at runtime from the credential/config store.
Weekly summary data accumulation
Breach and near-breach events are appended to an internal data store (platform-native key-value store or lightweight database table) by Workflow 2 throughout the week. Workflow 2's Monday morning schedule step reads and clears this store, compiles the Gmail payload, and resets the accumulator for the next week.
Credential store: complete list of required entries for SLA Monitoring and Breach Alerting automation
// Credential store entries (automation platform encrypted store)
// All values injected at runtime; never appear in workflow source code

ZENDESK_SUBDOMAIN            = '{subdomain}'          // e.g. 'yourcompany'
ZENDESK_API_EMAIL            = '{agent_email}'        // API token owner email
ZENDESK_API_TOKEN            = '{api_token}'          // Zendesk Admin > API
ZENDESK_CLIENT_ID_FIELD_ID   = '{field_id}'           // Custom field numeric ID

HUBSPOT_ACCESS_TOKEN         = '{private_app_token}'  // HubSpot Private App token
HUBSPOT_SLA_TIER_PROPERTY    = 'sla_tier'             // Company property internal name
HUBSPOT_BREACH_OBJECT_TYPE_ID= '{object_type_id}'     // Custom object type ID

SLACK_BOT_TOKEN              = 'xoxb-{token}'         // Slack App Bot OAuth token
SLACK_ALERT_CHANNEL_ID       = 'C{channel_id}'        // Fallback alert channel

PAGERDUTY_INTEGRATION_KEY    = '{routing_key}'        // Events API v2 integration key
PAGERDUTY_API_KEY            = '{rest_api_key}'       // Read-only REST key (optional)

GMAIL_CLIENT_ID              = '{oauth_client_id}'
GMAIL_CLIENT_SECRET          = '{oauth_client_secret}'
GMAIL_REFRESH_TOKEN          = '{oauth_refresh_token}'
GMAIL_SENDER_ADDRESS         = '{sender@domain.com}'
GMAIL_SUMMARY_RECIPIENT      = '{manager@domain.com}'

BUSINESS_HOURS_CONFIG        = '{json_string}'        // See config schema in Dev Handover Pack
// Example structure:
// { 'gold': { tz: 'America/New_York', start: '09:00', end: '17:00', days: [1,2,3,4,5] },
//   'silver': { tz: 'America/Chicago', start: '08:00', end: '18:00', days: [1,2,3,4,5] },
//   'bronze': { tz: 'America/Los_Angeles', start: '09:00', end: '17:00', days: [1,2,3,4,5] } }
The BUSINESS_HOURS_CONFIG entry is the most likely source of runtime errors before go-live. Confirm that every active SLA tier has a corresponding entry in this config object, that timezone strings use IANA format (e.g. 'America/New_York' not 'EST'), and that public holidays are accounted for if any SLA contracts exclude them. Missing or malformed entries will cause the business-hours calculation to return incorrect values without throwing an error.

05Error handling and retry logic

Every integration point in the automation has a defined failure behaviour. Unhandled exceptions must never fail silently. All errors must be logged to the automation platform's execution log, and any error that blocks an alert from reaching its destination must trigger a notification to support@gofullspec.com until the process owner nominates an internal escalation address.

Integration
Scenario
Required behaviour
Zendesk poll (Workflow 1)
HTTP 429 rate limit response on ticket list request
Retry after the Retry-After header value (default 60 seconds). Retry up to 3 times with exponential backoff (60s, 120s, 240s). If all retries fail, log the error, skip this poll cycle, and alert support@gofullspec.com. Do not carry partial results forward.
Zendesk poll (Workflow 1)
HTTP 401 or 403 on ticket list request (invalid or expired token)
Do not retry. Log the error with the response code and timestamp. Alert support@gofullspec.com immediately. Halt Workflow 1 execution for the current cycle. All downstream alerts are suppressed until credentials are restored.
HubSpot company lookup (Workflow 1)
Company ID from Zendesk does not match any HubSpot record (404 response)
Route the affected ticket to an internal 'unmatched_client' list. Continue processing all other tickets. After cycle completion, post a single Slack message to SLACK_ALERT_CHANNEL_ID listing all unmatched ticket IDs. Do not default to any SLA tier assumption.
HubSpot company lookup (Workflow 1)
sla_tier property is null or empty on matched company record
Treat identically to a 404 miss: route ticket to 'unmatched_client' list and include in the Slack summary. Log the HubSpot company ID alongside the ticket ID so the data gap can be corrected in HubSpot.
HubSpot company lookup (Workflow 1)
HTTP 429 rate limit on company lookup
Retry with 10-second delay between individual company lookups. Implement a per-cycle request counter; if 80% of the 100 requests/10 seconds limit is reached, pause the lookup loop for 30 seconds before resuming. Log any tickets skipped due to timeout.
Slack message send (Workflow 2)
Resolved Slack user ID not found for assigned agent email
Fall back to posting the alert to SLACK_ALERT_CHANNEL_ID with the agent's Zendesk display name mentioned in the message body. Log the failed user resolution. Do not suppress the alert.
Slack message send (Workflow 2)
HTTP 429 rate limit on chat.postMessage
Respect the Retry-After header. Queue remaining messages and send with a 1-second inter-message delay for the remainder of the cycle. All messages in the cycle must be delivered before the next poll cycle begins; if this is not possible, log which tickets were not alerted and include them in the next cycle's processing.
PagerDuty incident trigger (Workflow 2)
HTTP 400 invalid payload on Events API request
Do not retry. Log the full request payload and response body. Alert support@gofullspec.com with the ticket ID and error detail. As a manual fallback, post the escalation details to SLACK_ALERT_CHANNEL_ID so the manager is not left uninformed.
PagerDuty incident trigger (Workflow 2)
HTTP 202 accepted but no on-call person is currently scheduled
This is a PagerDuty configuration gap, not an API error. The automation cannot detect this condition directly. The PagerDuty escalation policy must include a catch-all secondary contact. FullSpec will verify escalation policy coverage during QA. Log all PagerDuty trigger responses for audit.
Zendesk internal note write (Workflow 2)
HTTP 422 unprocessable entity on ticket note PUT
Retry once after 30 seconds. If the retry fails, log the ticket ID and the note content that failed to post. Include in the weekly Gmail summary as a flagged audit gap. Do not block alert dispatch for other tickets.
HubSpot breach record creation (Workflow 2)
HTTP 400 or 422 on custom object POST
Retry once after 15 seconds. If the retry fails, log the full payload to the execution log. Append the failed breach record to an internal 'pending_breach_log' list. On the next successful poll cycle, attempt to flush the pending list before processing new events.
Gmail weekly summary send (Workflow 2)
OAuth token expired or revoked (HTTP 401 on token refresh)
Do not retry the send. Log the error with timestamp. Alert support@gofullspec.com immediately with instructions to re-authorise the Gmail OAuth credential. The weekly summary is not re-sent automatically once credentials are restored; a manual send or next-Monday scheduled run will be the next delivery.
General rule for all unhandled exceptions: any exception type not covered in the table above must be caught by a global error handler in each workflow. The global handler must log the exception type, the step name, the input payload (redacted of credential values), and the timestamp, then alert support@gofullspec.com. No workflow may terminate without writing a completion or error log entry. Silent failures are a build defect, not an acceptable outcome.
Integration and API SpecPage 4 of 4

More documents for this process

Every document generated for SLA Monitoring & Breach Alerting.

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