Back to IT Helpdesk Request Handling

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

IT Helpdesk Request Handling

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

This document is the authoritative integration reference for the IT Helpdesk Request Handling automation. It covers every tool connected in the workflow, exact authentication requirements, required OAuth scopes, field mappings between systems, credential store layout, orchestration architecture, and defined failure behaviours. The FullSpec team uses this specification during build and testing. Your team does not need to interact with this document directly, but the IT Manager should review Section 04 (credential store) to confirm that API keys are provisioned before build kick-off.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent(s)
Automation platform
Orchestration layer: hosts all three agent workflows, credential store, retry logic, and inter-agent triggers
Internal service account
Any plan supporting webhooks and scheduled polling
All agents
Freshdesk
Ticket creation, SLA tracking, technician assignment, and ticket status reads
API key (Basic Auth over HTTPS)
Growth plan or above (SLA policies, round-robin assignment)
Agent 1, Agent 2, Agent 3
Slack
Inbound request intake via slash command; outbound requester and technician notifications
OAuth 2.0 (Bot token)
Free tier sufficient; Pro required for message retention beyond 90 days
Agent 1, Agent 2
Google Workspace
Email intake via shared inbox (Gmail); Google Forms intake; forwarding parsed request body to Agent 1
OAuth 2.0 (service account with domain-wide delegation)
Business Starter or above
Agent 1
PagerDuty
SLA-breach escalation alerts for P1 and P2 tickets
REST API v2 (API key, Events API v2 integration key)
Professional plan or above (escalation policies, on-call schedules)
Agent 3
Notion
Knowledge base write: structured resolution summaries appended on ticket close
Notion API (Internal Integration Token)
Plus plan or above (API access enabled)
Agent 3
Before you connect anything: provision sandbox or test accounts for every tool listed above and validate all credentials, scopes, and webhook endpoints in the sandbox environment first. Do not enter production API keys into the automation platform until all integration tests in the Test and QA Plan have passed. Store all credentials exclusively in the shared credential store described in Section 04.

02Per-tool integration detail

Freshdesk

Primary ticketing system. Receives new ticket creation calls from Agent 1, assignment updates from Agent 2, and SLA-breach reads and status-change webhooks from Agent 3. All ticket operations use the Freshdesk REST API v2.

Auth method
HTTP Basic Auth: username = Freshdesk API key, password = any string (convention: 'X'). All requests over HTTPS to https://{FRESHDESK_SUBDOMAIN}.freshdesk.com/api/v2/
Required scopes
tickets:read, tickets:write, contacts:read, agents:read, groups:read, sla_policies:read — all granted implicitly via API key; no OAuth scope selection required
Webhook / trigger setup
Configure a Freshdesk Automation rule under Admin > Automations > Ticket Updates: fire a webhook to the automation platform's inbound URL when ticket status changes to 'Resolved'. Payload type: JSON. Include ticket ID, status, category, priority, and resolution notes. Validate webhook secret header X-Freshdesk-Signature against FRESHDESK_WEBHOOK_SECRET stored in credential store.
Required configuration
1. Custom ticket fields: cf_category (dropdown: hardware, software, access, general), cf_auto_triaged (checkbox). 2. SLA policy: P1 = 1 hr first response / 4 hr resolution; P2 = 2 hr / 8 hr; P3 = 8 hr / 24 hr; P4 = 24 hr / 72 hr. 3. Round-robin assignment group ID stored as FRESHDESK_GROUP_ID in credential store. 4. Technician agent IDs stored as FRESHDESK_AGENT_IDS (JSON array) in credential store — not hardcoded.
Rate limits
API: 1,000 calls/hour per account on Growth plan. At ~90 tickets/month (~312 runs/month including status checks), estimated API calls: ~1,500/month (~50/day, well under limit). Throttling logic: not required at current volume, but implement a 200 ms delay between batch calls as a precaution.
Constraints
Subdomain must be confirmed before build. API key must belong to an admin-level agent to allow ticket field writes and agent reads. Do not use a personal user API key; use a dedicated service account agent.
// Create ticket (POST)
POST /api/v2/tickets
{ "subject": "<parsed_subject>", "description": "<parsed_body>",
  "email": "<requester_email>", "priority": <1|2|3|4>,
  "status": 2, "group_id": FRESHDESK_GROUP_ID,
  "custom_fields": { "cf_category": "<category>", "cf_auto_triaged": true } }

// Read open tickets for load-balancing (GET)
GET /api/v2/tickets?filter=open&agent_id=<AGENT_ID>&per_page=100

// Update ticket assignment (PUT)
PUT /api/v2/tickets/{ticket_id}
{ "responder_id": <technician_agent_id> }

// Inbound webhook (ticket resolved) — payload excerpt
{ "ticket_id": 1042, "status": "resolved",
  "cf_category": "software", "resolution_notes": "...",
  "priority": 2, "requester_email": "user@example.com" }
Slack

Dual role: inbound intake channel via slash command (/it-request) and outbound notification channel for requester confirmation and technician alert messages. Uses the Slack Web API with a Bot OAuth token.

Auth method
OAuth 2.0 Bot token (xoxb-...). Install app to workspace via Slack App Directory or manifest. Token stored as SLACK_BOT_TOKEN in credential store.
Required scopes
commands (slash command registration), chat:write (post messages to channels and DMs), im:write (open DM channels), users:read (resolve user ID from email), users:read.email (look up Slack user by email address), channels:read (verify channel membership)
Webhook / trigger setup
1. Create a Slack App with a slash command: /it-request pointing to the automation platform's public inbound URL (SLACK_INTAKE_WEBHOOK_URL). 2. Enable Interactivity and Shortcuts if modal forms are used for structured intake. 3. Validate every inbound slash command request by verifying the X-Slack-Signature header using SLACK_SIGNING_SECRET stored in credential store. 4. Respond within 3 seconds with HTTP 200 and a deferred response_url message to avoid Slack timeout.
Required configuration
SLACK_REQUESTER_CHANNEL_ID: channel ID for requester DM (use users.conversations or im.open). SLACK_IT_ALERTS_CHANNEL_ID: channel ID for technician alerts (stored in credential store). IT manager Slack user ID stored as SLACK_MANAGER_USER_ID. Message templates use Block Kit JSON; template block IDs must not be hardcoded — load from credential store or config table.
Rate limits
Web API: Tier 3 endpoints (chat.postMessage) allow 1 request/second with burst tolerance. At ~90 notifications/month (2 per ticket plus escalations), estimated calls: ~200/month. Throttling not required; add 1 s delay between sequential DM sends.
Constraints
Bot must be invited to every channel it posts to before workflow runs. Slash command URL must be HTTPS with a valid TLS certificate. Slash command payload expires after 5 minutes; validate timestamp in signature check.
// Inbound slash command payload (POST from Slack)
{ "command": "/it-request", "text": "<user-typed request text>",
  "user_id": "U012AB3CD", "user_name": "jane.doe",
  "channel_id": "C04XXXXXXX", "response_url": "https://hooks.slack.com/..." }

// Outbound: notify requester (POST chat.postMessage)
{ "channel": "<requester_slack_user_id>",
  "blocks": [ { "type": "section", "text": { "type": "mrkdwn",
    "text": ":white_check_mark: Ticket #<id> logged. Priority: <P1-P4>. Assigned to: <name>." } } ] }

// Outbound: alert technician (POST chat.postMessage)
{ "channel": "<technician_slack_user_id>",
  "blocks": [ { "type": "section", "text": { "type": "mrkdwn",
    "text": ":bell: New ticket assigned: #<id> — <subject>. <freshdesk_ticket_url>" } } ] }
Google Workspace (Gmail + Google Forms)

Handles two intake paths: monitored shared inbox (Gmail) and a structured Google Form. The automation platform polls the shared inbox and listens for new Google Form submissions. Parsed request content is passed to Agent 1 for triage.

Auth method
OAuth 2.0 via a Google service account with domain-wide delegation. The service account JSON key is stored as GOOGLE_SERVICE_ACCOUNT_JSON in credential store. Delegated user: the shared inbox address (e.g. it-support@[YourCompany.com]).
Required scopes
https://www.googleapis.com/auth/gmail.readonly (read shared inbox messages), https://www.googleapis.com/auth/gmail.modify (mark messages as processed via label), https://www.googleapis.com/auth/forms.responses.readonly (read Google Form responses), https://www.googleapis.com/auth/drive.readonly (access Form response sheet if using Sheets as response destination)
Webhook / trigger setup
Gmail: use Gmail API push notifications (Cloud Pub/Sub) or poll via users.messages.list with label filter 'INBOX' and 'UNREAD' every 2 minutes. Apply a processed label (FRESHDESK_LOGGED) after parsing to prevent reprocessing. Google Forms: poll the linked Google Sheet (Sheet ID stored as GOOGLE_FORM_SHEET_ID) for new rows every 5 minutes using Sheets API v4. Track last-processed row index in the automation platform state store.
Required configuration
GOOGLE_SHARED_INBOX: shared inbox email address. GOOGLE_FORM_SHEET_ID: ID of the linked response spreadsheet. GOOGLE_PROCESSED_LABEL_ID: Gmail label ID for 'FRESHDESK_LOGGED' (create via Gmail API before go-live; store ID, not name). Form columns expected: Timestamp, Requester Email, Request Type (dropdown), Description, Urgency (dropdown).
Rate limits
Gmail API: 250 quota units/user/second; 1,000,000 units/day. Polling at 2-minute intervals with ~90 emails/month is negligible. Sheets API: 300 requests/minute per project. No throttling needed at current volume.
Constraints
Domain-wide delegation must be approved by a Google Workspace Super Admin before the service account can impersonate the shared inbox. OAuth consent screen must be set to internal. Do not use a personal user's OAuth token.
// Gmail poll — parsed message structure passed to Agent 1
{ "source": "gmail", "message_id": "18d4f...",
  "from_email": "requester@example.com",
  "subject": "Can't access VPN",
  "body_text": "Since this morning I cannot connect to the VPN from home.",
  "received_at": "2025-01-22T09:14:00Z" }

// Google Form row — parsed structure passed to Agent 1
{ "source": "google_form", "row_index": 47,
  "requester_email": "requester@example.com",
  "request_type": "access", "description": "Need access to SharePoint site.",
  "urgency": "medium", "submitted_at": "2025-01-22T09:22:00Z" }
Integration and API SpecPage 1 of 3
FS-DOC-05Technical
PagerDuty

Receives SLA-breach trigger calls from Agent 3 when a P1 or P2 Freshdesk ticket has not been resolved within the defined SLA window. Fires an alert to the on-call IT manager via the configured escalation policy.

Auth method
Two keys required: 1. PagerDuty REST API key (for service and policy reads) stored as PAGERDUTY_API_KEY. 2. Events API v2 integration key (routing key) for firing incidents stored as PAGERDUTY_ROUTING_KEY. Both stored in credential store.
Required scopes
PagerDuty REST API v2: REST API key grants full account access by scope of key type (read-only key is insufficient; use a full-access key scoped to the IT service only). Events API v2: routing key is tied to a specific PagerDuty service; no additional scope selection.
Webhook / trigger setup
No inbound webhook from PagerDuty is required for this automation. Outbound only: Agent 3 calls the Events API v2 endpoint (https://events.pagerduty.com/v2/enqueue) with a trigger event payload when an SLA breach is detected. PagerDuty service ID stored as PAGERDUTY_SERVICE_ID. Escalation policy ID stored as PAGERDUTY_ESCALATION_POLICY_ID.
Required configuration
Create a PagerDuty Service named 'IT Helpdesk SLA Alerts' with the escalation policy pointing to the IT manager as the first on-call responder. Set the integration type to 'Events API v2'. SLA breach thresholds (P1: 60 min, P2: 120 min) must match Freshdesk SLA policy settings exactly to avoid duplicate or missed alerts.
Rate limits
Events API v2: no documented per-minute limit; PagerDuty recommends no more than 10 concurrent trigger requests. At a maximum of a few P1/P2 breaches per month (estimated 3 to 5), throttling is not applicable.
Constraints
PagerDuty account must be on Professional plan or above to use escalation policies with on-call schedules. Do not trigger 'acknowledge' or 'resolve' events from the automation platform; resolution must be a manual action by the IT manager in PagerDuty to preserve audit trail.
// Trigger SLA breach alert (POST Events API v2)
POST https://events.pagerduty.com/v2/enqueue
{ "routing_key": "<PAGERDUTY_ROUTING_KEY>",
  "event_action": "trigger",
  "dedup_key": "freshdesk-ticket-<ticket_id>-sla-breach",
  "payload": {
    "summary": "SLA breach: Ticket #<ticket_id> — <subject>",
    "severity": "critical",
    "source": "Freshdesk",
    "custom_details": {
      "ticket_id": "<ticket_id>",
      "priority": "P1",
      "elapsed_minutes": 75,
      "freshdesk_url": "https://<subdomain>.freshdesk.com/helpdesk/tickets/<ticket_id>"
    }
  }
}
Notion

Knowledge base write target. Agent 3 appends a structured page to a designated Notion database every time a Freshdesk ticket is marked resolved. Each page captures category, resolution summary, fix steps, and ticket metadata.

Auth method
Notion Internal Integration Token (Bearer token). Create an internal integration at https://www.notion.so/my-integrations. Token stored as NOTION_INTEGRATION_TOKEN in credential store. The integration must be explicitly added to the target database page (Share > Invite > select integration name).
Required scopes
internal_integration capabilities: insert_content (write pages to database), read_content (read database schema for field validation). Notion internal integrations do not use OAuth scopes; capabilities are set at integration creation time.
Webhook / trigger setup
No inbound webhook required. Notion is write-only in this workflow. Agent 3 is triggered by the Freshdesk resolved-ticket webhook described above. No polling of Notion is needed.
Required configuration
NOTION_KB_DATABASE_ID: the Notion database ID (32-character string from the database URL) stored in credential store. Database schema must include these properties before go-live: Title (title type), Category (select: hardware, software, access, general), Priority (select: P1, P2, P3, P4), Ticket ID (number), Requester Email (email), Resolution Date (date), Fix Steps (rich_text), Resolution Summary (rich_text). Property names must match exactly (case-sensitive) as used in the API payload.
Rate limits
Notion API: 3 requests/second average; burst allowed. At ~90 resolved tickets/month (~3/day), rate limiting is not a concern. Add a 400 ms delay between sequential writes if batching is ever needed during backfill.
Constraints
Notion API does not support upsert natively; the integration must check for an existing page by Ticket ID before creating a new one to avoid duplicate knowledge base entries. Use a pages.query filter on the Ticket ID property for this check. Block size limit per rich_text property: 2,000 characters; truncate resolution notes if exceeded and append a link to the Freshdesk ticket for full detail.
// Create KB page (POST Notion pages API)
POST https://api.notion.com/v1/pages
Authorization: Bearer <NOTION_INTEGRATION_TOKEN>
Notion-Version: 2022-06-28
{
  "parent": { "database_id": "<NOTION_KB_DATABASE_ID>" },
  "properties": {
    "Title":           { "title": [{ "text": { "content": "<subject>" } }] },
    "Category":        { "select": { "name": "<category>" } },
    "Priority":        { "select": { "name": "P<1-4>" } },
    "Ticket ID":       { "number": <ticket_id> },
    "Requester Email": { "email": "<requester_email>" },
    "Resolution Date": { "date": { "start": "<ISO8601_date>" } },
    "Fix Steps":       { "rich_text": [{ "text": { "content": "<fix_steps>" } }] },
    "Resolution Summary": { "rich_text": [{ "text": { "content": "<summary>" } }] }
  }
}

03Field mappings between tools

The tables below define the exact field mapping for each agent handoff in the workflow. Source and destination field names are written as they appear in the respective API payloads. All field names are case-sensitive.

Agent 1 handoff: Intake source (Gmail or Slack or Google Forms) to Freshdesk ticket creation

Source tool
Source field
Destination tool
Destination field
Gmail
`from_email`
Freshdesk
`email`
Gmail
`subject`
Freshdesk
`subject`
Gmail
`body_text`
Freshdesk
`description`
Gmail
`received_at`
Freshdesk
`created_at` (read-only; set automatically)
Slack (/it-request)
`user_id` resolved via users.info to `profile.email`
Freshdesk
`email`
Slack (/it-request)
`text`
Freshdesk
`description`
Slack (/it-request)
`text` (first 80 chars)
Freshdesk
`subject`
Google Forms
`Requester Email`
Freshdesk
`email`
Google Forms
`Description`
Freshdesk
`description`
Google Forms
`Request Type`
Freshdesk
`custom_fields.cf_category`
Triage Agent output
`priority_score` (1-4)
Freshdesk
`priority`
Triage Agent output
`category`
Freshdesk
`custom_fields.cf_category`
Triage Agent output
`auto_triaged: true`
Freshdesk
`custom_fields.cf_auto_triaged`

Agent 2 handoff: Freshdesk ticket to Slack notifications (requester and technician)

Source tool
Source field
Destination tool
Destination field
Freshdesk
`id`
Slack message body
`text` (formatted as Ticket #`id`)
Freshdesk
`subject`
Slack message body
`text` (ticket subject line)
Freshdesk
`priority`
Slack message body
`text` (mapped P1/P2/P3/P4)
Freshdesk
`responder_id`
Freshdesk agents API
`name` and `email` (looked up before Slack send)
Freshdesk
`responder.name`
Slack message body (requester DM)
`text` (assigned technician name)
Freshdesk
`email`
Slack users API
`user_id` (looked up via users.lookupByEmail)
Freshdesk
`id` + subdomain
Slack message body (technician DM)
`url` (https://`FRESHDESK_SUBDOMAIN`.freshdesk.com/helpdesk/tickets/`id`)

Agent 3 handoff: Freshdesk resolved ticket to Notion knowledge base

Source tool
Source field
Destination tool
Destination field
Freshdesk webhook
`ticket_id`
Notion
`properties.Ticket ID`
Freshdesk webhook
`subject`
Notion
`properties.Title`
Freshdesk webhook
`custom_fields.cf_category`
Notion
`properties.Category`
Freshdesk webhook
`priority`
Notion
`properties.Priority` (mapped: 1=P1, 2=P2, 3=P3, 4=P4)
Freshdesk webhook
`requester_email`
Notion
`properties.Requester Email`
Freshdesk webhook
`resolution_notes`
Notion
`properties.Resolution Summary`
Freshdesk webhook
`resolution_notes` (structured fix steps parsed by Agent 3)
Notion
`properties.Fix Steps`
Freshdesk webhook
`updated_at`
Notion
`properties.Resolution Date`

Agent 3 handoff: Freshdesk SLA breach detection to PagerDuty

Source tool
Source field
Destination tool
Destination field
Freshdesk (polled)
`id`
PagerDuty Events API
`dedup_key` (prefix: freshdesk-ticket-)
Freshdesk (polled)
`subject`
PagerDuty Events API
`payload.summary`
Freshdesk (polled)
`priority`
PagerDuty Events API
`payload.severity` (P1/P2 = critical)
Freshdesk (polled)
`created_at` vs current time
PagerDuty Events API
`payload.custom_details.elapsed_minutes`
Freshdesk (polled)
`id` + subdomain URL
PagerDuty Events API
`payload.custom_details.freshdesk_url`
Integration and API SpecPage 2 of 3
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Three discrete workflows (one per agent) running on the automation platform. Each workflow is independently deployable and testable. A shared credential store provides all API keys and configuration values; no credentials are hardcoded in any workflow definition. Inter-agent communication is event-driven: Agent 2 is triggered by a Freshdesk ticket creation event produced by Agent 1; Agent 3 is triggered by a Freshdesk webhook on ticket resolution and by a scheduled SLA-check poll.
Agent 1 trigger mechanism
Three parallel intake paths: (1) Gmail poll every 2 minutes using Gmail API users.messages.list; (2) Google Forms response poll every 5 minutes via Sheets API v4 on GOOGLE_FORM_SHEET_ID; (3) Slack slash command inbound webhook (push, no polling). All three paths normalise to a common request payload before invoking triage logic. Slack slash command signature validated via HMAC-SHA256 using SLACK_SIGNING_SECRET before any processing.
Agent 2 trigger mechanism
Webhook push from the automation platform's internal event bus, fired by Agent 1 immediately after successful Freshdesk ticket creation. Payload includes Freshdesk ticket ID, priority, category, and requester email. No polling required for Agent 2.
Agent 3 trigger mechanism
Two triggers: (1) Inbound webhook from Freshdesk (ticket status = resolved) validated via X-Freshdesk-Signature HMAC-SHA256 using FRESHDESK_WEBHOOK_SECRET; fires knowledge base write to Notion. (2) Scheduled poll every 15 minutes: reads all open Freshdesk tickets with priority 1 or 2, calculates elapsed time since creation, and fires PagerDuty trigger if elapsed time exceeds SLA threshold. Poll uses a state store to track dedup_keys already sent to PagerDuty within the current breach window.
Credential store structure
All secrets stored in the automation platform's encrypted credential store under namespaced keys. See code block below. No values are stored in workflow node configuration fields or environment variable files committed to source control.
Workflow versioning
Each workflow is version-controlled in the automation platform. Changes require a version increment before deployment to production. The Test and QA Plan must be re-run for any change affecting an API call, field mapping, or trigger mechanism.
Credential store key names — store values in the automation platform's encrypted secret manager only
// Credential store contents — all keys namespaced by tool
// Values are secret; this block documents key names only

// Freshdesk
FRESHDESK_API_KEY           = "<api_key>"                  // Admin service account API key
FRESHDESK_SUBDOMAIN         = "yourcompany"                 // e.g. yourcompany.freshdesk.com
FRESHDESK_GROUP_ID          = "<integer>"                   // Round-robin assignment group ID
FRESHDESK_AGENT_IDS         = "[<id1>, <id2>, <id3>]"       // JSON array of technician agent IDs
FRESHDESK_WEBHOOK_SECRET    = "<hmac_secret>"               // For validating resolved-ticket webhook

// Slack
SLACK_BOT_TOKEN             = "xoxb-<...>"                  // Bot OAuth token
SLACK_SIGNING_SECRET        = "<signing_secret>"            // For validating slash command requests
SLACK_IT_ALERTS_CHANNEL_ID  = "C04XXXXXXX"                  // Channel for technician alerts
SLACK_MANAGER_USER_ID       = "U04XXXXXXX"                  // IT manager Slack user ID
SLACK_INTAKE_WEBHOOK_URL    = "https://..."                  // Public URL for /it-request slash command

// Google Workspace
GOOGLE_SERVICE_ACCOUNT_JSON = "{ ... }"                     // Full service account JSON key (escaped)
GOOGLE_SHARED_INBOX         = "it-support@[YourCompany.com]" // Delegated inbox address
GOOGLE_FORM_SHEET_ID        = "<spreadsheet_id>"            // Google Sheets ID for form responses
GOOGLE_PROCESSED_LABEL_ID   = "<label_id>"                  // Gmail label ID for processed emails

// PagerDuty
PAGERDUTY_API_KEY           = "<rest_api_key>"              // Full-access REST API key
PAGERDUTY_ROUTING_KEY       = "<events_api_v2_key>"         // Events API v2 integration routing key
PAGERDUTY_SERVICE_ID        = "<service_id>"                // IT Helpdesk SLA Alerts service ID
PAGERDUTY_ESCALATION_POLICY_ID = "<policy_id>"              // Escalation policy ID

// Notion
NOTION_INTEGRATION_TOKEN    = "secret_<...>"                // Internal integration Bearer token
NOTION_KB_DATABASE_ID       = "<32_char_database_id>"       // Target knowledge base database ID

// Orchestration platform state
STATE_FORM_LAST_ROW         = <integer>                      // Last processed Google Form row index
STATE_PD_DEDUP_KEYS         = "[<dedup_key>, ...]"           // PagerDuty dedup keys sent this window
Rotate all API keys and tokens immediately if any are accidentally committed to source control, logged in plain text, or exposed in a webhook payload. The Freshdesk API key and PagerDuty routing key carry the highest blast radius and should be rotated first. Contact support@gofullspec.com if a credential exposure is suspected during the build phase.

05Error handling and retry logic

Every integration point in the workflow has a defined failure behaviour. Unhandled exceptions must never fail silently. Any error not matched by a specific handler below must be caught by the global exception handler, logged with full context (timestamp, workflow ID, step name, HTTP status or error message, input payload hash), and trigger a Slack alert to SLACK_MANAGER_USER_ID.

Integration
Scenario
Required behaviour
Gmail poll (Agent 1)
Gmail API returns 401 Unauthorized
Halt poll. Log error with credential key name. Alert IT manager via Slack. Do not retry until credential is refreshed. Raise to FullSpec support.
Gmail poll (Agent 1)
Gmail API returns 429 or 500-series error
Retry with exponential backoff: 30 s, 60 s, 120 s (max 3 attempts). If all retries fail, log and alert IT manager. Resume on next scheduled poll cycle.
Slack slash command (Agent 1)
Signature validation fails (tampered or expired request)
Return HTTP 403 immediately. Log the source IP and timestamp. Do not process the payload. No retry. Alert IT manager if three failures occur within 10 minutes.
Slack slash command (Agent 1)
Automation platform fails to respond within 3 s
Return HTTP 200 immediately with a deferred 'Working on it...' message to response_url. Continue processing asynchronously. If processing fails, post error message to response_url.
Freshdesk ticket creation (Agent 1)
POST /api/v2/tickets returns 422 Unprocessable Entity (invalid field value)
Log full request payload and response body. Do not retry automatically. Alert IT manager with the raw request text so the ticket can be created manually. Flag triage rule for review.
Freshdesk ticket creation (Agent 1)
POST /api/v2/tickets returns 503 or timeout
Retry up to 3 times with exponential backoff: 15 s, 45 s, 90 s. If all retries fail, store the normalised request payload to a dead-letter queue and alert IT manager to log manually.
Freshdesk agent list read (Agent 2)
GET /api/v2/agents returns empty array (all agents unavailable)
Assign ticket to FRESHDESK_GROUP_ID (unassigned group) instead. Send Slack alert to IT manager that load-balancing failed and manual assignment is required. Log the ticket ID.
Slack message send (Agent 2)
chat.postMessage returns channel_not_found or not_in_channel
Log the failed channel ID and Slack user ID. Retry once after 10 s. If retry fails, fall back to sending the notification via email to the requester and technician email addresses using Gmail API.
PagerDuty trigger (Agent 3)
Events API v2 returns 400 Bad Request (invalid routing key)
Halt PagerDuty calls. Log error and routing key reference. Alert IT manager via Slack immediately with ticket ID and elapsed SLA time so manual escalation can be performed. Do not retry until key is corrected.
PagerDuty trigger (Agent 3)
Events API v2 returns 429 or 5xx
Retry up to 3 times with backoff: 20 s, 60 s, 180 s. If all retries fail, send a direct Slack message to SLACK_MANAGER_USER_ID with full ticket details as manual escalation fallback.
Notion page creation (Agent 3)
POST /v1/pages returns 404 (database not found or integration not shared)
Log database ID reference and error. Do not retry. Alert IT manager that knowledge base write failed and include the resolution summary as plain text in the alert so it can be pasted manually.
Notion page creation (Agent 3)
POST /v1/pages returns 409 conflict or duplicate Ticket ID detected on pre-check
Skip page creation. Log that a duplicate was detected. Do not overwrite existing KB entry. Alert IT manager if the resolution notes differ significantly (more than 100 characters) from existing entry.
Freshdesk webhook (Agent 3)
Webhook signature validation fails on resolved-ticket event
Return HTTP 403. Discard payload. Log timestamp and source IP. Do not write to Notion or trigger any downstream action. Alert IT manager if this occurs more than once in a 60-minute window.
Global (all agents)
Unhandled exception: any error not matched by a specific handler above
Catch exception in global handler. Log full context: timestamp, workflow ID, step name, HTTP status, error message, input payload hash (not raw payload). Send Slack alert to SLACK_MANAGER_USER_ID. Never fail silently.
Dead-letter queue: any payload that exhausts all retries without a successful outcome must be written to a dedicated dead-letter log (date, workflow ID, tool, step, payload summary) accessible to the FullSpec team and the IT manager. Review dead-letter entries at least weekly during the first month post-launch. Contact support@gofullspec.com to review persistent failure patterns.
Integration and API SpecPage 3 of 3

More documents for this process

Every document generated for IT Helpdesk Request Handling.

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