Back to Warranty & Guarantee Claim 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

Warranty and Guarantee Claim Handling

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

This document defines every integration point in the Warranty and Guarantee Claim Handling automation: the tools connected, the exact credentials and scopes required, the field mappings between systems, the orchestration layout, and the error handling behaviour expected at each failure point. It is written for the FullSpec build team and assumes familiarity with REST APIs, OAuth 2.0, and webhook signature validation. Nothing in this document is owner-facing. All credential values are stored in the shared credential store; no secrets are hardcoded in workflow definitions.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agents
Orchestration layer
Hosts all workflow definitions, credential store, and retry logic
N/A (internal)
N/A
All agents
Gmail
Inbound claim detection via monitored inbox; outbound acknowledgement send
OAuth 2.0 (Google)
Google Workspace (any tier)
Agent 1, Agent 3
Zendesk
Ticket creation, field population, resolution send, and ticket closure
API token + subdomain (Basic Auth header)
Zendesk Suite Team or above
Agent 1, Agent 3
Shopify
Order and purchase record lookup by customer email or order number
OAuth 2.0 (Shopify Partner app) or private app API key
Basic Shopify or above
Agent 2
Google Sheets
Warranty rules reference read; claim tracker row write
OAuth 2.0 (Google service account)
Google Workspace (any tier)
Agent 2
Slack
Manager approval request message; approval or rejection callback
OAuth 2.0 (Slack app bot token)
Slack Pro or above (interactive messages require paid plan)
Agent 2
Xero
Referenced for refund processing context; not directly called by automation in Standard build
OAuth 2.0 (Xero app)
Xero Starter or above
Out of automated scope (manual finance step)
Before you connect anything: sandbox-test every integration using non-production credentials before switching to live credentials. For Gmail and Google Sheets, use a dedicated service account or test Google Workspace user. For Zendesk, use the sandbox subdomain. For Shopify, use a development store. For Slack, use a private test workspace. Connecting production credentials to an untested workflow risks sending real emails to real customers or overwriting live tracker data.

02Per-tool integration detail

Gmail

Used by Agent 1 (Claim Intake Agent) to monitor the designated claims inbox for new inbound emails and by Agent 3 (Resolution Confirmation Agent) to send outbound acknowledgement emails where Zendesk email is not used as the send channel.

Auth method
OAuth 2.0 via Google Identity Platform. A dedicated service account is created under the Google Workspace org; domain-wide delegation is enabled so the automation platform can impersonate the claims inbox address (e.g. claims@[YourCompany.com]) without storing a user password.
Required scopes
https://www.googleapis.com/auth/gmail.readonly (inbox poll); https://www.googleapis.com/auth/gmail.send (outbound send); https://www.googleapis.com/auth/gmail.modify (mark as read / apply label after processing)
Trigger setup
Poll interval: every 2 minutes against the claims inbox using the Gmail API messages.list endpoint with query parameter q=is:unread label:warranty-claims. On each poll, fetch full message body for any unread threads. After processing, apply the label processed-by-automation and mark as read via messages.modify. Do not delete.
Required configuration
Gmail label warranty-claims must exist before go-live and must be applied to the monitored address by a forwarding filter or manually. Label ID is stored in the credential store (GMAIL_CLAIM_LABEL_ID), not hardcoded. Sender address for outbound is stored as GMAIL_SEND_AS_ADDRESS in the credential store.
Rate limits
Gmail API quota: 250 quota units per user per second; messages.list costs 5 units; messages.get costs 5 units; messages.send costs 100 units. At 55 claims/month (~2 per day) the automation is well within limits. No throttling required at current volume. Monitor quota dashboard if volume exceeds 500 claims/month.
Constraints
OAuth refresh tokens expire if unused for 6 months. The orchestration layer must store and auto-refresh the access token using the refresh token. Service account delegation must be re-confirmed if the Google Workspace admin changes domain security policies.
// Input
Gmail API: GET /gmail/v1/users/me/messages?q=is:unread+label:warranty-claims
// Returns list of message IDs
Gmail API: GET /gmail/v1/users/me/messages/{id}?format=full
// Returns full RFC 2822 message with headers and body parts
// Output
Parsed object -> { from_email, subject, body_text, received_timestamp, attachments[] }
Passed to Agent 1 claim extraction step
Zendesk

Used by Agent 1 (Claim Intake Agent) to create structured tickets and by Agent 3 (Resolution Confirmation Agent) to post the final resolution reply and close the ticket.

Auth method
API token authentication: HTTP Basic Auth with header Authorization: Basic base64({admin_email}/token:{api_token}). Token is stored in credential store as ZENDESK_API_TOKEN. Subdomain stored as ZENDESK_SUBDOMAIN.
Required scopes
Zendesk API tokens carry the full permission set of the generating admin account. Scope the token to a dedicated automation agent user account in Zendesk with the Agent role. Required permissions: tickets:read, tickets:write, users:read. No end-user-facing admin permissions required.
Webhook/trigger setup
Zendesk webhook (outbound): configure a Zendesk trigger named Notify automation on new portal submission that fires on ticket created via web form, posting a JSON payload to the orchestration layer inbound webhook URL. The orchestration layer validates the request using a shared HMAC-SHA256 secret stored as ZENDESK_WEBHOOK_SECRET. Gmail-originated claims bypass this webhook and are handled via the Gmail poll path.
Required configuration
Zendesk custom ticket fields must be pre-created: warranty_claim_id (text), order_number (text), product_sku (text), purchase_date (date), claim_resolution_type (dropdown: replacement, refund, rejection, pending), escalation_required (checkbox). Field IDs are stored in the credential store as ZENDESK_FIELD_IDS (JSON map). Automation agent user ID stored as ZENDESK_AGENT_USER_ID.
Rate limits
Zendesk Suite Team: 700 requests per minute per account. Each claim touches approximately 4 API calls (create ticket, update fields, post comment, close ticket). At 55 claims/month the rate is negligible. No throttling required at current volume.
Constraints
Ticket closure via API sets status to solved, not closed; Zendesk auto-closes solved tickets after the configured period (default 28 days). Do not attempt to set status directly to closed via API as this is not permitted on Suite Team. The HMAC signature on inbound webhooks must be validated before processing; reject any request with an invalid signature and log to the error channel.
// Input (ticket creation)
POST /api/v2/tickets
{ subject, comment: { body }, requester: { email, name },
  custom_fields: [ {id: FIELD_ID, value: ...}, ... ],
  tags: ['warranty-claim', 'auto-intake'] }
// Input (resolution reply and close)
PUT /api/v2/tickets/{ticket_id}
{ status: 'solved', comment: { body: resolution_text, public: true } }
// Output
ticket_id, ticket_url -> passed to downstream agents
Shopify

Used by Agent 2 (Eligibility and Routing Agent) to retrieve the original order record for a claimant, confirming product SKU, purchase date, and order total.

Auth method
Shopify private app API key for single-store installs, or OAuth 2.0 custom app for multi-store. API key and password stored in credential store as SHOPIFY_API_KEY and SHOPIFY_API_PASSWORD. Store domain stored as SHOPIFY_STORE_DOMAIN.
Required scopes
read_orders (required to query order history); read_customers (required to look up customer record by email). No write scopes required for the Standard build. Scope string for OAuth app: read_orders,read_customers
Trigger setup
No webhook from Shopify is used in this direction. The automation platform calls Shopify synchronously when Agent 2 runs. Query by customer email first (GET /admin/api/2024-01/orders.json?email={email}&status=any&limit=50); if no match, attempt query by order number extracted from the claim form (GET /admin/api/2024-01/orders/{order_id}.json).
Required configuration
SHOPIFY_STORE_DOMAIN, SHOPIFY_API_KEY, SHOPIFY_API_PASSWORD stored in credential store. API version pinned to 2024-01 and stored as SHOPIFY_API_VERSION; update on each Shopify quarterly release after regression testing.
Rate limits
Shopify REST API: 2 requests per second (leaky bucket, burst to 40). Each claim triggers 1 to 2 API calls. At 55 claims/month (average 2/day) no throttling is needed. If volume exceeds 100 claims/day, implement a 500ms delay between calls. Monitor the X-Shopify-Shop-Api-Call-Limit response header.
Constraints
Order lookup by email will fail if the customer used a different email at checkout than on the claim form. In this case the workflow must write an internal Zendesk note flagging manual lookup required and halt the automated eligibility path. Do not guess or fuzzy-match orders. Order number must be surfaced on the claim form as a recommended (not mandatory) field to provide a fallback identifier.
// Input
GET /admin/api/2024-01/orders.json
  ?email={claimant_email}&status=any&limit=50
// Fallback input
GET /admin/api/2024-01/orders/{order_number}.json
// Output
order_id, order_number, created_at (purchase_date),
line_items[0].sku (product_sku),
line_items[0].price (unit_price),
total_price (order_total)
-> passed to Google Sheets eligibility check step
Google Sheets

Used by Agent 2 (Eligibility and Routing Agent) for two operations: read from the warranty rules reference sheet to check eligibility, and write a new or updated row to the claims tracker sheet.

Auth method
OAuth 2.0 via Google service account with domain-wide delegation. Service account JSON key stored in credential store as GOOGLE_SERVICE_ACCOUNT_JSON. The service account is granted Editor access to both sheets directly (not via a shared drive).
Required scopes
https://www.googleapis.com/auth/spreadsheets (read and write to Sheets API v4); https://www.googleapis.com/auth/drive.file (access only files created by or shared with the service account, not full Drive access)
Required configuration
SHEETS_WARRANTY_RULES_ID: Spreadsheet ID of the warranty rules reference sheet. SHEETS_CLAIM_TRACKER_ID: Spreadsheet ID of the claims tracker sheet. SHEETS_RULES_RANGE: named range or A1 notation for the warranty rules table (e.g. WarrantyRules!A2:E). SHEETS_TRACKER_RANGE: sheet name for append target (e.g. ClaimsLog!A:M). All four values stored in credential store. Sheet structure must match the field mapping table in Section 03.
Warranty rules sheet structure
Columns: product_sku (A), warranty_period_days (B), max_refund_value (C), eligible_fault_types (D, comma-separated), escalation_threshold_usd (E). One row per product SKU or SKU prefix. A wildcard row with sku=DEFAULT covers products not individually listed.
Claim tracker sheet structure
Columns: claim_id (A), zendesk_ticket_id (B), claimant_email (C), product_sku (D), order_number (E), purchase_date (F), claim_date (G), eligibility_verdict (H), resolution_type (I), escalation_required (J), manager_decision (K), resolved_date (L), notes (M).
Rate limits
Google Sheets API v4: 300 read requests per minute per project; 300 write requests per minute per project. Each claim triggers 1 read (rules lookup) and 1 write (tracker append). At 55 claims/month no throttling is needed. Implement exponential backoff on 429 responses regardless.
Constraints
Do not perform cell-by-cell writes; use a single spreadsheets.values.append call per claim to write the full tracker row atomically. If the warranty rules sheet is empty or the SKU lookup returns no match, the workflow must fall back to the DEFAULT row and flag the claim for manual review.
// Input (rules read)
GET spreadsheets/{SHEETS_WARRANTY_RULES_ID}/values/{SHEETS_RULES_RANGE}
// Filter rows where column A matches product_sku from Shopify
// Output (rules read)
warranty_period_days, max_refund_value, escalation_threshold_usd
// Input (tracker write)
POST spreadsheets/{SHEETS_CLAIM_TRACKER_ID}/values/{SHEETS_TRACKER_RANGE}:append
  valueInputOption=USER_ENTERED
  body: { values: [[ claim_id, zendesk_ticket_id, claimant_email, ... ]] }
// Output
updatedRange confirming row appended
Slack

Used by Agent 2 (Eligibility and Routing Agent) to send structured approval request messages to the approving manager for claims flagged as high-value or out-of-scope, and to receive the manager's interactive approve or reject callback.

Auth method
OAuth 2.0 Slack app with bot token. Bot token stored in credential store as SLACK_BOT_TOKEN. Signing secret for request verification stored as SLACK_SIGNING_SECRET. The Slack app must be installed to the workspace with the bot added to the approval channel.
Required scopes
chat:write (post messages to channels and DMs); chat:write.public (post to public channels without joining); incoming-webhook (optional, for simple message posting); channels:read (resolve channel name to ID). Interactive components require no additional scope but the app must have an interactivity request URL configured pointing to the orchestration layer inbound webhook endpoint.
Webhook/trigger setup
Outbound: the automation platform calls the Slack Web API chat.postMessage endpoint to send the approval block kit message. Inbound: the manager clicks Approve or Reject in the Slack message; Slack POSTs an interaction payload to the orchestration layer endpoint (SLACK_INTERACTION_ENDPOINT). The endpoint validates the request timestamp and HMAC-SHA256 signature using SLACK_SIGNING_SECRET before processing. Requests older than 5 minutes are rejected.
Required configuration
SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET, SLACK_APPROVAL_CHANNEL_ID (ID of the channel where approval requests are posted), SLACK_TIMEOUT_HOURS (default: 4; after this period without a response the timeout escalation path fires). All stored in credential store. The approving manager must be a member of SLACK_APPROVAL_CHANNEL_ID.
Approval message payload structure
Block Kit message with a header section (claim reference, claimant name, product SKU, order total, resolution type recommended), a context section (Zendesk ticket URL, purchase date, days since purchase, escalation reason), and two action buttons: Approve (value: approve) and Reject (value: reject), both carrying the claim_id and zendesk_ticket_id in the action value JSON.
Rate limits
Slack Web API: Tier 3 methods (chat.postMessage) allow 1 request per second burst. At 55 claims/month with an estimated 22% escalation rate (~12 escalations/month) there is no throttling concern. Implement 1 second delay between consecutive Slack API calls if batching.
Constraints
Interactive message buttons expire if the Slack message is older than the app's configured interaction timeout. Set SLACK_TIMEOUT_HOURS to match the business SLA. If no interaction is received within SLACK_TIMEOUT_HOURS, the orchestration layer must trigger the timeout escalation path (re-notify manager via DM, then flag claim in tracker as awaiting-manual-review). Never leave a claim stalled indefinitely.
// Outbound message input
POST https://slack.com/api/chat.postMessage
{ channel: SLACK_APPROVAL_CHANNEL_ID,
  blocks: [ header_block, fields_block, actions_block ],
  text: 'Warranty claim approval required: {claim_id}' }
// Inbound interaction payload (from manager button click)
POST {SLACK_INTERACTION_ENDPOINT}
payload: { type: 'block_actions', actions: [{ action_id: 'approve|reject',
  value: '{claim_id}:{zendesk_ticket_id}' }],
  user: { id, name } }
// Output
manager_decision (approve | reject), decided_by, decided_at
-> passed to Resolution Confirmation Agent
Integration and API SpecPage 1 of 3
FS-DOC-05Technical

03Field mappings between tools

The tables below define every field handoff between tools across all three agent steps. Use exact field names as shown; these are the keys referenced in the orchestration layer data mappings. All field names are case-sensitive.

Agent 1 handoff: Gmail or Zendesk web form to Zendesk ticket

Source tool
Source field
Destination tool
Destination field
Gmail
from_email
Zendesk
requester.email
Gmail
from_name
Zendesk
requester.name
Gmail
subject
Zendesk
subject
Gmail
body_text
Zendesk
comment.body
Gmail
received_timestamp
Zendesk
custom_fields[claim_submission_date]
Gmail / Form
order_number (extracted)
Zendesk
custom_fields[order_number]
Gmail / Form
product_sku (extracted)
Zendesk
custom_fields[product_sku]
Zendesk form
ticket.id
Orchestration
claim_id (internal)
Zendesk form
ticket.requester.email
Orchestration
claimant_email

Agent 2 handoff: Zendesk ticket to Shopify order lookup

Source tool
Source field
Destination tool
Destination field
Zendesk
requester.email
Shopify
orders?email={value}
Zendesk
custom_fields[order_number]
Shopify
orders/{value}.json (fallback)

Agent 2 handoff: Shopify order response to Google Sheets eligibility check

Source tool
Source field
Destination tool
Destination field
Shopify
orders[0].created_at
Google Sheets
rules lookup: days_since_purchase (computed)
Shopify
orders[0].line_items[0].sku
Google Sheets
rules row filter: product_sku (col A)
Shopify
orders[0].total_price
Google Sheets
eligibility check: order_total vs escalation_threshold_usd (col E)
Google Sheets
warranty_period_days (col B)
Orchestration
eligibility_verdict (within_period: bool)
Google Sheets
max_refund_value (col C)
Orchestration
max_refund_value
Google Sheets
eligible_fault_types (col D)
Orchestration
fault_type_match (bool)
Google Sheets
escalation_threshold_usd (col E)
Orchestration
escalation_required (bool)

Agent 2 handoff: Eligibility result to Google Sheets claim tracker

Source tool
Source field
Destination tool
Destination field
Orchestration
claim_id
Google Sheets
ClaimsLog col A: claim_id
Zendesk
ticket.id
Google Sheets
ClaimsLog col B: zendesk_ticket_id
Zendesk
requester.email
Google Sheets
ClaimsLog col C: claimant_email
Shopify
orders[0].line_items[0].sku
Google Sheets
ClaimsLog col D: product_sku
Shopify
orders[0].order_number
Google Sheets
ClaimsLog col E: order_number
Shopify
orders[0].created_at
Google Sheets
ClaimsLog col F: purchase_date
Orchestration
claim_timestamp
Google Sheets
ClaimsLog col G: claim_date
Orchestration
eligibility_verdict
Google Sheets
ClaimsLog col H: eligibility_verdict
Orchestration
resolution_type
Google Sheets
ClaimsLog col I: resolution_type
Orchestration
escalation_required
Google Sheets
ClaimsLog col J: escalation_required
Slack
manager_decision
Google Sheets
ClaimsLog col K: manager_decision

Agent 3 handoff: Slack callback or auto-approve result to Zendesk resolution

Source tool
Source field
Destination tool
Destination field
Slack / Orchestration
manager_decision (approve | reject)
Zendesk
comment.body (resolution message text)
Orchestration
resolution_type
Zendesk
custom_fields[claim_resolution_type]
Orchestration
zendesk_ticket_id
Zendesk
ticket.id (PUT endpoint target)
Slack
user.name (decided_by)
Google Sheets
ClaimsLog col K: manager_decision (append decided_by)
Orchestration
resolved_timestamp
Google Sheets
ClaimsLog col L: resolved_date
Integration and API SpecPage 2 of 3
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Three discrete workflows, one per agent: Claim Intake Agent workflow, Eligibility and Routing Agent workflow, and Resolution Confirmation Agent workflow. Workflows are chained by event: Agent 1 emits a claim_created event that triggers Agent 2; Agent 2 emits an approval_decision event (or auto_approve event) that triggers Agent 3. A single shared credential store is used across all three workflows.
Agent 1 trigger mechanism
Dual-path trigger. Path A: scheduled poll of the Gmail inbox every 2 minutes using the Gmail API messages.list endpoint. Path B: inbound webhook from Zendesk (new portal ticket trigger). The workflow deduplicates by claim_id (derived from Zendesk ticket ID or Gmail message ID) before processing. Both paths converge at the ticket creation step.
Agent 2 trigger mechanism
Webhook trigger. Agent 1 emits a claim_created internal event containing claim_id and zendesk_ticket_id. Agent 2 listens on an internal event bus endpoint (not publicly exposed). No polling required. Signature validation uses the same HMAC-SHA256 mechanism as external webhooks; the shared secret is INTERNAL_EVENT_SECRET stored in the credential store.
Agent 3 trigger mechanism
Webhook trigger on two paths. Path A: Slack interaction payload posted to SLACK_INTERACTION_ENDPOINT when manager clicks Approve or Reject. Signature validated using SLACK_SIGNING_SECRET (X-Slack-Signature header, timestamp check). Path B: internal auto_approve event emitted by Agent 2 when the claim is within standard warranty terms and below the escalation threshold. Both paths converge at the resolution send step.
Slack timeout escalation
Agent 2 schedules a timeout job at the time the Slack approval message is sent. The job fires after SLACK_TIMEOUT_HOURS (default: 4 business hours). If manager_decision is still null at that point, the timeout job posts a DM to the manager as a reminder and updates the claim tracker escalation_required field to timeout-pending. A second timeout after a further 2 hours flags the claim as awaiting-manual-review and posts an alert to the Slack channel.
Deduplication mechanism
Each workflow execution stores claim_id in a short-lived key-value cache (TTL: 24 hours) before processing. If the same claim_id is received again within 24 hours, the duplicate execution is discarded and logged. This prevents double-ticketing from simultaneous Gmail poll and Zendesk webhook firing for the same submission.
Environment separation
Three environments: development (Zendesk sandbox, Gmail test inbox, Shopify dev store, Sheets test spreadsheets, Slack test workspace), staging (mirror of production credentials but separate Zendesk sandbox), production. Credential store namespaces: dev/*, staging/*, prod/*. Promotion between environments requires an explicit credential swap; no environment shares live credentials with another.

Credential store contents (all values stored as encrypted secrets; none hardcoded in workflow definitions):

Credential store entries — all values are placeholders; replace with live values before promotion to production
// Gmail
GOOGLE_SERVICE_ACCOUNT_JSON       = { ... full service account key JSON ... }
GMAIL_CLAIM_LABEL_ID              = 'Label_XXXXXXXXXXXXXXXXX'
GMAIL_SEND_AS_ADDRESS             = 'claims@[YourCompany.com]'

// Zendesk
ZENDESK_SUBDOMAIN                 = '[yourcompany]'
ZENDESK_ADMIN_EMAIL               = 'automation@[YourCompany.com]'
ZENDESK_API_TOKEN                 = 'ZENDESK_TOKEN_XXXXXXXXXXXXXX'
ZENDESK_AGENT_USER_ID             = '000000000000'
ZENDESK_WEBHOOK_SECRET            = 'WEBHOOK_HMAC_SECRET_XXXXXXXXX'
ZENDESK_FIELD_IDS                 = '{"warranty_claim_id":360001,"order_number":360002,"product_sku":360003,"purchase_date":360004,"claim_resolution_type":360005,"escalation_required":360006}'

// Shopify
SHOPIFY_STORE_DOMAIN              = '[yourcompany].myshopify.com'
SHOPIFY_API_KEY                   = 'SHOPIFY_KEY_XXXXXXXXXXXXXXXXX'
SHOPIFY_API_PASSWORD              = 'SHOPIFY_PWD_XXXXXXXXXXXXXXXXX'
SHOPIFY_API_VERSION               = '2024-01'

// Google Sheets
SHEETS_WARRANTY_RULES_ID          = '1BxiMVs0XRA5nFMdKvBdBZjgmUUqptlbs74OgVE2upms'
SHEETS_CLAIM_TRACKER_ID           = '1BxiMVs0XRA5nFMdKvBdBZjgmUUqptlbs74OgVE2uXXX'
SHEETS_RULES_RANGE                = 'WarrantyRules!A2:E'
SHEETS_TRACKER_RANGE              = 'ClaimsLog!A:M'

// Slack
SLACK_BOT_TOKEN                   = 'xoxb-XXXXXXXXXXXX-XXXXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXXX'
SLACK_SIGNING_SECRET              = 'SLACK_SIGNING_SECRET_XXXXXXXXX'
SLACK_APPROVAL_CHANNEL_ID         = 'C0XXXXXXXXXX'
SLACK_INTERACTION_ENDPOINT        = 'https://hooks.[orchestration-platform]/slack/interact'
SLACK_TIMEOUT_HOURS               = '4'

// Internal
INTERNAL_EVENT_SECRET             = 'INTERNAL_HMAC_SECRET_XXXXXXXXX'
DEDUP_CACHE_TTL_SECONDS           = '86400'
Never commit credential values to version control. All secrets are injected at runtime from the credential store. If a secret is rotated (e.g. Zendesk API token or Slack signing secret), update the credential store entry and re-test the affected integration path in staging before applying to production.

05Error handling and retry logic

Every integration point has a defined failure behaviour. Unhandled exceptions must never fail silently. All errors are written to the orchestration platform error log, and any error that stalls a claim must trigger an alert to the support lead via Slack (channel: #automation-alerts). Retry logic uses exponential backoff unless otherwise stated.

Integration
Scenario
Required behaviour
Gmail poll
Gmail API returns 401 Unauthorized (token expired)
Orchestration layer attempts token refresh using stored refresh token. If refresh succeeds, retry the poll immediately. If refresh fails, send alert to #automation-alerts and pause the poll workflow until credentials are re-confirmed. Do not silently skip the poll cycle.
Gmail poll
Gmail API returns 429 or 500 (quota exceeded or server error)
Apply exponential backoff: retry at 30s, 2min, 10min intervals (3 attempts). If all retries fail, log the failure with the poll cycle timestamp and resume at the next scheduled poll. Flag any emails that may have been missed in the error log.
Zendesk webhook (inbound)
HMAC signature validation fails on inbound webhook payload
Reject the request with HTTP 401. Log the source IP, timestamp, and payload hash. Do not process the ticket. Alert #automation-alerts immediately. Investigate for replay or spoofing before re-enabling the endpoint.
Zendesk API (ticket creation)
POST /api/v2/tickets returns 422 Unprocessable Entity (invalid field value)
Log the full request payload and error response. Do not retry automatically (retrying will produce the same error). Post an internal Zendesk note to a fallback triage ticket alerting the support lead. Claim must be manually created by support staff.
Zendesk API (ticket creation)
POST /api/v2/tickets returns 503 or network timeout
Retry with exponential backoff: 15s, 1min, 5min (3 attempts). If all retries fail, store the ticket payload in the orchestration layer dead-letter queue and alert #automation-alerts. Support lead to manually create the ticket from the stored payload within 30 minutes.
Shopify order lookup
No order found matching claimant_email or order_number
Do not attempt fuzzy matching. Write an internal Zendesk ticket note: 'Order not found for email {claimant_email}. Manual order lookup required before eligibility check can proceed.' Set claim tracker row escalation_required = manual-lookup. Halt the automated eligibility path for this claim.
Shopify order lookup
Shopify API returns 429 (rate limit hit)
Read X-Shopify-Shop-Api-Call-Limit response header. If bucket is above 80% utilised, wait until bucket drops below 50% before retrying. Maximum 3 retries. If limit still exceeded, place claim in retry queue with a 5-minute delay and log. At current volume (55 claims/month) this scenario is not expected.
Google Sheets (rules read)
Warranty rules sheet returns no matching SKU row and no DEFAULT row exists
Treat claim as unable-to-auto-assess. Set eligibility_verdict = manual-review-required in the tracker. Add internal Zendesk note. Alert support lead. Do not reject the claim automatically. Warranty rules sheet must have a DEFAULT row to prevent this scenario.
Google Sheets (tracker write)
spreadsheets.values.append returns 403 Forbidden (service account permission error)
Log the error with the full claim payload. Retry once after 30 seconds. If retry fails, write the claim row data to the orchestration error log in structured JSON so it can be manually pasted into the tracker. Alert #automation-alerts.
Slack (approval message send)
chat.postMessage returns error: channel_not_found or not_in_channel
Alert the orchestration administrator via email (support@gofullspec.com) and to the fallback alert channel if one exists. Escalate the claim immediately to manual review status. Do not leave the claim waiting for Slack approval if the channel is unreachable.
Slack (approval interaction)
Manager does not respond within SLACK_TIMEOUT_HOURS
Timeout job fires: send manager a DM reminder with the claim details and approve/reject link. Log timeout event to claim tracker (col K: timeout-pending). If no response after a further 2 hours, update tracker to awaiting-manual-review and post alert to #automation-alerts. Never leave a claim stalled indefinitely.
Zendesk API (resolution send and close)
PUT /api/v2/tickets/{id} returns 404 (ticket not found)
Log the missing ticket ID and the resolution payload. Alert #automation-alerts. Support lead must manually locate the ticket (or create one) and apply the resolution. This scenario indicates a ticket was deleted or merged between Agent 1 and Agent 3 execution; investigate root cause.
All dead-letter queue items (failed payloads that exhausted retries) must be reviewed by the FullSpec team within one business day of occurrence. Dead-letter items are never discarded automatically. Contact support@gofullspec.com to report a recurring failure pattern or to request a credential rotation procedure.
Integration and API SpecPage 3 of 3

More documents for this process

Every document generated for Warranty & Guarantee Claim 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