Back to End-of-day / Shift Handover

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

End-of-day / Shift Handover

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

This document defines every integration point, authentication requirement, scope string, field mapping, and failure behaviour for the End-of-day / Shift Handover automation. It is written for the FullSpec engineering team responsible for configuring the orchestration layer and connecting the six named tools. It is not intended for the business owner. Every credential, scope, and configuration value in this spec must be validated in a sandbox environment before any production credential is touched.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent(s)
Orchestration layer
Hosts all workflows, manages credentials, handles scheduling and retries
Internal service account
Self-hosted or vendor SaaS tier
All
Google Forms
Collects structured end-of-shift data from outgoing staff
OAuth 2.0 (Google)
Free (Google account)
Agent 1
Google Sheets
Centralised shift log; trigger surface and data store for both agents
OAuth 2.0 (Google)
Free (Google account)
Agent 1, Agent 2
Slack
Sends staff prompts and distributes compiled handover report
OAuth 2.0 (Slack) + Bot token
Pro ($8/user/month)
Agent 1, Agent 2
Notion
Long-term archive of finalised handover reports
OAuth 2.0 (Notion) or Internal Integration token
Plus ($10/user/month)
Agent 2
Gmail
Emails handover report to incoming manager and on-call contacts
OAuth 2.0 (Google)
Free (Google account)
Agent 2
PagerDuty
Raises on-call alerts for unresolved incidents flagged in the compiled report
REST API key (service-level)
Professional ($21/user/month)
Agent 2
Before you connect anything: create a sandbox or staging instance for every tool listed above. Validate OAuth flows and webhook delivery against test accounts before any production credential is stored in the credential store. Never paste a production token directly into a workflow node during development.

02Per-tool integration detail

Google Forms

Used by Agent 1 (Handover Collector Agent) to present staff with a structured end-of-shift data entry form. Responses are captured automatically in the linked Google Sheet via the Forms native response destination. The orchestration layer does not call the Forms API directly for submission; it reads resulting data from Sheets.

Auth method
OAuth 2.0 with a Google service account. The service account must be granted Editor access to the target Form so it can read the response schema and modify form structure if field updates are required post-launch.
Required scopes
https://www.googleapis.com/auth/forms.body.readonly | https://www.googleapis.com/auth/forms.responses.readonly | https://www.googleapis.com/auth/drive.readonly (to enumerate the linked response Sheet)
Webhook / trigger setup
Not applicable for form submission. The Forms API does not support push webhooks natively. Response delivery to Sheets is handled by the Google Forms native response destination. The Sheets webhook or poll (see Google Sheets entry) detects new rows.
Required configuration
Form ID stored in the credential store as GFORMS_FORM_ID. Response destination must be linked to the canonical GSHEETS_LOG_SHEET_ID before go-live. Question item IDs must be mapped to Sheets column headers during setup and stored in config (not hardcoded in workflow nodes). Do not add or reorder form questions after go-live without updating the Sheets column map.
Rate limits
Forms API: 100 requests per 100 seconds per user. At ~10 handovers/week with 5-15 staff per shift, total API calls remain well below this ceiling. No throttling required at current volume.
Constraints
The Google Forms API does not support real-time push notification. All response detection depends on the linked Google Sheet. Form structure changes after launch invalidate stored field mappings and require a full re-test of Agent 1 column logic.
Google Sheets

Used by both agents. Agent 1 appends staff form responses as new rows and writes a 'log_ready' status flag. Agent 2 reads the completed log to compile the handover report. The Sheet also serves as the manual shift-close trigger surface: a team lead can write 'CLOSE' into a designated trigger cell to fire the workflow outside the scheduled time.

Auth method
OAuth 2.0 with the same Google service account used for Forms. The service account must have Editor access to the response Sheet.
Required scopes
https://www.googleapis.com/auth/spreadsheets | https://www.googleapis.com/auth/drive.file
Webhook / trigger setup
Agent 1 trigger: the orchestration layer polls the Sheet every 2 minutes during the 15-minute window following the scheduled shift-end time, checking for new rows in the 'responses' tab. For the manual shift-close path, the orchestration layer polls the 'control' tab cell B2 for the value 'CLOSE' on the same 2-minute cycle. On detection, it clears the cell and proceeds. Polling interval must not drop below 60 seconds to avoid rate-limit pressure.
Required configuration
GSHEETS_LOG_SHEET_ID (Spreadsheet ID, stored in credential store). GSHEETS_RESPONSES_TAB_NAME defaults to 'shift_responses'. GSHEETS_CONTROL_TAB_NAME defaults to 'control'. GSHEETS_LOG_READY_CELL defaults to 'control!B3'. Column header names must match Form question item labels exactly; these mappings are stored in a JSON config file in the credential store, not hardcoded.
Rate limits
Sheets API v4: 300 read requests per minute per project; 60 write requests per minute per user. At 10 handovers/week with polling every 2 minutes across a 15-minute window, total reads peak at approximately 7-8 per handover cycle. No throttling required at current volume.
Constraints
Appending rows outside the expected schema (e.g. extra columns from a modified Form) will cause Agent 2 to read incorrect field offsets. Schema changes require a coordinated update to the Form, the Sheets column map, and the Agent 2 read logic simultaneously.
Slack

Used by Agent 1 to send the end-of-shift prompt and Google Forms link to outgoing staff, and by Agent 2 to post the compiled handover report to the designated operations channel. Both interactions use the Slack Web API via a single Bot token scoped to the workspace.

Auth method
OAuth 2.0 app installation. A Slack App must be created in the workspace, installed with Bot token scopes, and the Bot token stored as SLACK_BOT_TOKEN in the credential store. Do not use a legacy API token.
Required scopes
chat:write | chat:write.public | channels:read | users:read | users:read.email | im:write (for direct-message fallback)
Webhook / trigger setup
No inbound webhook is required for this integration. All Slack calls are outbound from the orchestration layer. If a future version requires staff to respond via Slack interactive messages, the app will need the Event Subscriptions endpoint configured with request URL validation (HMAC-SHA256 signature verification against the SLACK_SIGNING_SECRET credential).
Required configuration
SLACK_BOT_TOKEN stored in the credential store. SLACK_OPS_CHANNEL_ID (the target operations channel Slack ID, not the display name). SLACK_FORM_LINK (the direct Google Forms URL included in the staff prompt message). SLACK_PROMPT_TEMPLATE_ID (key for the message template stored in config). Channel IDs must be used, not channel names, to survive channel renames.
Rate limits
Slack Web API: Tier 3 methods (chat.postMessage) allow 50+ requests per minute. At 10 handovers/week with a maximum of 20 staff messages plus 1 channel post per handover, peak usage is approximately 21 API calls per cycle. No throttling required at current volume.
Constraints
The Bot must be manually invited to any private channel before it can post. Bot token scopes cannot be changed without reinstalling the app and generating a new token. Store the new token immediately in the credential store and verify the existing workflow nodes pick it up without hardcoded references.
Integration and API SpecPage 1 of 4
FS-DOC-05Technical
Notion

Used by Agent 2 (Handover Compiler Agent) to file the finalised handover report as a new page inside the designated Notion database. Each page corresponds to a single shift and is dated and tagged automatically. This creates the searchable audit trail that replaces the manual Notion filing step.

Auth method
Notion Internal Integration token (preferred for single-workspace use). Create an integration at notion.so/my-integrations, generate a token, and share the target database with the integration. Store the token as NOTION_INTEGRATION_TOKEN in the credential store.
Required scopes
Notion integrations use capability flags rather than OAuth scopes. Required capabilities: Read content, Insert content, Update content. The integration must have these three capabilities enabled and must be explicitly shared with the handover report database by a workspace admin.
Webhook / trigger setup
Not applicable. Notion does not provide outbound webhooks. All calls are outbound from Agent 2 to the Notion API. Agent 2 creates a new database page via POST /v1/pages on each completed handover cycle.
Required configuration
NOTION_INTEGRATION_TOKEN in the credential store. NOTION_DATABASE_ID (the target database ID extracted from the database URL, stored in the credential store, not hardcoded). Page property mappings: 'Shift Date' (date property), 'Shift ID' (text property), 'Status' (select: Open, Closed, Escalated), 'Report Body' (rich text). These property names must match the actual database schema exactly, including capitalisation.
Rate limits
Notion API: 3 requests per second average; burst up to 90 requests per 30 seconds. At 10 handovers/week, a maximum of 1 page creation call per handover cycle places zero pressure on the rate limit. No throttling required at current volume.
Constraints
Notion database property names are case-sensitive. A mismatch between the config property name and the actual database schema will cause a silent 400 error with no page created. The integration token must be reshared with the database if the database is moved to a different workspace section. Token rotation requires a credential store update and workflow restart.
Gmail

Used by Agent 2 to email the compiled handover report to the incoming shift manager and any on-call contacts registered for that shift. The email is sent from a designated sender address using OAuth-authorised access. No SMTP relay or third-party mail service is required.

Auth method
OAuth 2.0 with a Google service account authorised for domain-wide delegation, OR OAuth 2.0 with a dedicated Gmail user account. The chosen account must be the sender address visible to recipients. Store the refresh token as GMAIL_OAUTH_REFRESH_TOKEN and the sender address as GMAIL_SENDER_ADDRESS in the credential store.
Required scopes
https://www.googleapis.com/auth/gmail.send (send-only; do not request broader gmail.modify or gmail.readonly scopes unless read access is specifically required by a future feature)
Webhook / trigger setup
Not applicable for outbound sending. Agent 2 calls the Gmail API messages.send method directly. If inbound reply processing is added in a future version, Gmail push notifications via Cloud Pub/Sub would be required.
Required configuration
GMAIL_OAUTH_REFRESH_TOKEN in the credential store. GMAIL_SENDER_ADDRESS (the From address). GMAIL_RECIPIENT_LIST_KEY (a reference to the list of recipient addresses stored in config, not hardcoded in the workflow node). GMAIL_REPORT_SUBJECT_TEMPLATE (e.g. 'Shift Handover Report - {shift_date} - {shift_id}'). Email body is generated by Agent 2 from the compiled report text and formatted as HTML using a stored template.
Rate limits
Gmail API: 250 quota units per user per second; messages.send costs 100 units per call. At 10 handovers/week with 1-3 recipients per handover, peak usage is approximately 30 send calls per week. No throttling required at current volume.
Constraints
OAuth refresh tokens expire if unused for 6 months or if the authorising user revokes access. The credential store must be checked and tokens refreshed proactively as part of quarterly maintenance. Sending from a service account using domain-wide delegation requires a Google Workspace admin to configure the delegation; a standard Gmail account using user OAuth avoids this but requires the authorising user's account to remain active.
PagerDuty

Used by Agent 2 to raise an on-call escalation alert when the compiled handover report contains one or more unresolved incidents or high-priority equipment flags. The alert is created via the PagerDuty Events API v2, targeting the configured service integration key.

Auth method
PagerDuty Events API v2 uses an Integration Key (routing key) per service, not a user API key. Store the integration key as PAGERDUTY_INTEGRATION_KEY in the credential store. For any REST API v2 calls (e.g. listing incidents), a separate user or service API key stored as PAGERDUTY_API_KEY is required.
Required scopes
PagerDuty does not use OAuth scopes for the Events API. The Integration Key is scoped to the specific PagerDuty service configured for shift escalations. For REST API v2 access, the API key must belong to a user with the 'Responder' role at minimum. No broader admin permissions are needed for this integration.
Webhook / trigger setup
Not applicable for alert creation. Agent 2 sends a POST request to https://events.pagerduty.com/v2/enqueue with the event payload. If the operations team wants PagerDuty to push acknowledgement status back to the orchestration layer, a PagerDuty webhook subscription (V3 webhooks) must be configured, with the orchestration layer endpoint URL registered and the webhook signature header X-PagerDuty-Signature validated against PAGERDUTY_WEBHOOK_SECRET.
Required configuration
PAGERDUTY_INTEGRATION_KEY (the service integration routing key, stored in the credential store). PAGERDUTY_SERVICE_ID (used for REST API calls if needed). PAGERDUTY_ESCALATION_POLICY_ID (the on-call escalation policy to associate with triggered incidents). Alert severity mapping: 'unresolved_incident' maps to severity 'critical'; 'equipment_flag' maps to severity 'warning'. These mappings are stored in config, not hardcoded.
Rate limits
PagerDuty Events API v2: no published hard rate limit for inbound events; PagerDuty recommends staying below 1 event per second per integration key. At 10 handovers/week with at most 1 alert per handover, this is not a concern. No throttling required at current volume.
Constraints
The integration key is tied to a single PagerDuty service. Routing to different on-call teams requires separate integration keys per service. If the escalation policy changes (e.g. new on-call rota), the PAGERDUTY_ESCALATION_POLICY_ID must be updated in the credential store. The Events API v2 does not return a PagerDuty incident ID synchronously in all cases; do not rely on a synchronous incident ID for downstream logic without handling the asynchronous creation pattern.

03Field mappings between tools

The tables below define the exact field mappings at each agent handoff point. All field names are written in monospace as they appear in API responses, Sheet column headers, or JSON payloads. Any deviation in naming between the source tool and the destination tool will cause a silent null or mapping failure.

Handoff A: Google Forms responses to Google Sheets (Agent 1 responsibility)

Source tool
Source field
Destination tool
Destination field
Google Forms
Timestamp
Google Sheets
response_timestamp
Google Forms
Email Address
Google Sheets
staff_email
Google Forms
Staff Name
Google Sheets
staff_name
Google Forms
Tasks Completed (list)
Google Sheets
tasks_completed
Google Forms
Tasks In Progress (list)
Google Sheets
tasks_in_progress
Google Forms
Tasks Blocked (list)
Google Sheets
tasks_blocked
Google Forms
Incidents Flagged (text)
Google Sheets
incidents_flagged
Google Forms
Equipment Issues (text)
Google Sheets
equipment_issues
Google Forms
Priority Items for Incoming Team (text)
Google Sheets
priority_items
Google Forms
Shift ID (hidden field)
Google Sheets
shift_id

Handoff B: Google Sheets log to Agent 2 compiled report fields (Agent 2 read step)

Source tool
Source field
Destination tool
Destination field
Google Sheets
shift_id
Handover Compiler Agent
report.shift_id
Google Sheets
response_timestamp
Handover Compiler Agent
report.collected_at
Google Sheets
staff_name
Handover Compiler Agent
report.staff_responses[].name
Google Sheets
tasks_completed
Handover Compiler Agent
report.staff_responses[].completed
Google Sheets
tasks_in_progress
Handover Compiler Agent
report.staff_responses[].in_progress
Google Sheets
tasks_blocked
Handover Compiler Agent
report.staff_responses[].blocked
Google Sheets
incidents_flagged
Handover Compiler Agent
report.incidents[]
Google Sheets
equipment_issues
Handover Compiler Agent
report.equipment_flags[]
Google Sheets
priority_items
Handover Compiler Agent
report.priority_items[]
Google Sheets
log_ready
Handover Compiler Agent
trigger.log_ready_flag

Handoff C: Compiled report fields to Notion page properties (Agent 2 file step)

Source tool
Source field
Destination tool
Destination field
Handover Compiler Agent
report.shift_id
Notion
Shift ID (text property)
Handover Compiler Agent
report.shift_date
Notion
Shift Date (date property)
Handover Compiler Agent
report.status
Notion
Status (select: Open | Closed | Escalated)
Handover Compiler Agent
report.body_html
Notion
Report Body (rich text / page content)
Handover Compiler Agent
report.incidents[]
Notion
Open Incidents (multi-select or rich text)

Handoff D: Compiled report fields to PagerDuty event payload (Agent 2 escalation step)

Source tool
Source field
Destination tool
Destination field
Handover Compiler Agent
report.shift_id
PagerDuty Events API v2
payload.custom_details.shift_id
Handover Compiler Agent
report.incidents[]
PagerDuty Events API v2
payload.summary (concatenated incident titles)
Handover Compiler Agent
report.escalation_severity
PagerDuty Events API v2
payload.severity (critical | warning)
Handover Compiler Agent
report.shift_date
PagerDuty Events API v2
payload.timestamp (ISO 8601)
Handover Compiler Agent
report.body_url
PagerDuty Events API v2
links[0].href (Notion page URL)
Integration and API SpecPage 2 of 4
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Two discrete workflows, one per agent. Workflow 1 corresponds to the Handover Collector Agent; Workflow 2 corresponds to the Handover Compiler Agent. Workflows are linked by a shared status flag in Google Sheets (control!B3 = 'READY'), not by a direct inter-workflow call. This decouples the two agents and allows each to be debugged independently.
Credential store
A single centralised credential store is used by both workflows. All tokens, keys, IDs, and template references are retrieved from the store at runtime. No credential or configuration ID is hardcoded in any workflow node.
Agent 1 trigger mechanism
Scheduled poll. The orchestration layer evaluates a time-based schedule matching the configured shift-end times (stored in config, not hardcoded). At each scheduled time it checks the Google Sheets control tab for a shift-close signal. It also polls the same control tab every 2 minutes for a manual 'CLOSE' value written by a team lead, enabling out-of-schedule trigger. No inbound webhook is required for Agent 1.
Agent 2 trigger mechanism
Poll with condition check. Workflow 2 polls the Google Sheets control tab cell B3 every 60 seconds for the value 'READY', which is written by Workflow 1 once the response window has closed and the log is confirmed as written. On detection, Workflow 2 clears the flag, reads the full log, and proceeds. This avoids a direct workflow-to-workflow call and is resilient to orchestration layer restarts between agents.
Webhook signature validation
Not required for the current Agent 1 and Agent 2 implementations, which use outbound calls only. If Slack interactive message callbacks or PagerDuty inbound webhooks are added, HMAC-SHA256 signature validation must be implemented before any webhook endpoint is exposed. The signing secret must be stored as SLACK_SIGNING_SECRET or PAGERDUTY_WEBHOOK_SECRET in the credential store.
Shift schedule configuration
Shift-end times are stored in a config object within the credential store (key: SHIFT_SCHEDULE), not as hardcoded cron expressions in the workflow. This allows the operations team to update shift times without requiring a workflow republish. The orchestration layer reads this config at each trigger evaluation cycle.
Environment separation
Maintain separate credential store environments for development, staging, and production. Staging credentials must point to sandbox accounts for all six tools. Promotion from staging to production requires a deliberate credential swap, not a single shared token set.

Credential store contents (all keys required before either workflow is activated in production):

Credential store keys (all environments; values populated per environment)
// Google (shared OAuth service account or per-user refresh tokens)
GOOGLE_OAUTH_CLIENT_ID          = '<oauth_client_id>'
GOOGLE_OAUTH_CLIENT_SECRET      = '<oauth_client_secret>'
GOOGLE_OAUTH_REFRESH_TOKEN      = '<refresh_token_for_service_account_or_sender_user>'

// Google Forms
GFORMS_FORM_ID                  = '<google_forms_form_id>'

// Google Sheets
GSHEETS_LOG_SHEET_ID            = '<spreadsheet_id>'
GSHEETS_RESPONSES_TAB_NAME      = 'shift_responses'
GSHEETS_CONTROL_TAB_NAME        = 'control'
GSHEETS_LOG_READY_CELL          = 'control!B3'
GSHEETS_COLUMN_MAP              = '<JSON string mapping Form question IDs to Sheet column letters>'

// Slack
SLACK_BOT_TOKEN                 = 'xoxb-<token>'
SLACK_SIGNING_SECRET            = '<signing_secret_for_future_webhook_validation>'
SLACK_OPS_CHANNEL_ID            = 'C<channel_id>'
SLACK_FORM_LINK                 = 'https://forms.gle/<form_short_url>'
SLACK_PROMPT_TEMPLATE_ID        = 'shift_end_prompt_v1'

// Notion
NOTION_INTEGRATION_TOKEN        = 'secret_<token>'
NOTION_DATABASE_ID              = '<32_char_database_id>'

// Gmail
GMAIL_SENDER_ADDRESS            = 'handover-bot@[YourCompany.com]'
GMAIL_RECIPIENT_LIST_KEY        = 'shift_recipient_list'
GMAIL_REPORT_SUBJECT_TEMPLATE   = 'Shift Handover Report - {shift_date} - {shift_id}'

// PagerDuty
PAGERDUTY_INTEGRATION_KEY       = '<events_api_v2_routing_key>'
PAGERDUTY_API_KEY               = '<rest_api_v2_user_or_service_key>'
PAGERDUTY_SERVICE_ID            = '<service_id>'
PAGERDUTY_ESCALATION_POLICY_ID  = '<policy_id>'
PAGERDUTY_WEBHOOK_SECRET        = '<webhook_signing_secret_for_future_use>'

// Orchestration config
SHIFT_SCHEDULE                  = '<JSON array of shift_end_times in HH:MM local format>'
RESPONSE_WINDOW_MINUTES         = '10'
ESCALATION_SEVERITY_MAP         = '{"unresolved_incident":"critical","equipment_flag":"warning"}'
Never commit credential store values to source control. Use the orchestration platform's native secret management or a dedicated vault. Rotate all tokens on a 90-day cycle and immediately after any team member with access to the credential store leaves the project.

05Error handling and retry logic

Every integration point has a defined failure behaviour. Unhandled exceptions must never fail silently. All errors must be logged with a timestamp, the workflow run ID, the failing node name, the HTTP status or exception type, and the input payload that caused the failure. Where a retry sequence is defined below, use exponential backoff starting at the stated initial interval.

Integration
Scenario
Required behaviour
Google Sheets (Agent 1 poll)
Sheet is unreachable or returns 5xx at scheduled trigger time
Retry 3 times with exponential backoff: 30 s, 60 s, 120 s. If all retries fail, post an error alert to SLACK_OPS_CHANNEL_ID with the message 'Handover trigger failed: Sheets unreachable. Manual collection required.' Log the full error. Do not proceed to form distribution.
Slack (Agent 1 staff prompt)
chat.postMessage fails for one or more staff members (user not in workspace, channel not found, or rate limit hit)
Retry failed messages up to 2 times with a 10-second delay. If the user DM fails, fall back to posting the prompt in SLACK_OPS_CHANNEL_ID with the staff member's display name mentioned. Log each failed DM with the recipient user ID.
Google Forms (response collection)
No responses are received within the RESPONSE_WINDOW_MINUTES window
After the response window closes, Agent 1 writes whatever rows are present to the Sheets log (even if zero rows) and sets log_ready = 'PARTIAL'. Agent 2 detects this flag and includes a 'Missing responses' section in the compiled report listing which staff did not submit. Never block Agent 2 from running because of missing responses.
Google Sheets (Agent 1 row append)
Append call returns 429 Too Many Requests
Retry with exponential backoff: 15 s, 30 s, 60 s. If the row cannot be appended after 3 retries, write the failed row payload to a dead-letter log tab named 'append_errors' with a timestamp. Alert the ops channel. Do not discard the row silently.
Google Sheets (Agent 2 read)
Sheet returns schema mismatch (unexpected column count or header names)
Agent 2 must validate column headers against GSHEETS_COLUMN_MAP before reading any data. On mismatch, abort the run, post an error to the ops channel, and log the expected vs. actual header array. Do not attempt to parse misaligned data.
Notion (report filing)
POST /v1/pages returns 400 (property name mismatch) or 401 (token revoked)
On 400: log the full Notion error body and the property payload sent. Alert the ops channel. Do not retry until the property mismatch is resolved manually. On 401: attempt a token refresh if using OAuth; if using an integration token, alert support@gofullspec.com immediately and log the failure. The compiled report must still be posted to Slack and Gmail even if Notion filing fails.
Notion (report filing)
POST /v1/pages returns 503 or times out
Retry 3 times with exponential backoff: 20 s, 60 s, 180 s. After 3 failures, store the report payload in a Sheets tab named 'notion_retry_queue' with a failed_at timestamp. A scheduled retry job must attempt reprocessing from this queue every 30 minutes until the page is successfully created.
Gmail (report email)
messages.send returns 401 (token expired) or 403 (quota exceeded)
On 401: trigger an OAuth token refresh using the stored refresh token. Retry the send once after a successful refresh. If the refresh fails, log the error and alert the ops channel. On 403: log the quota error and retry after 60 seconds once. If still failing, log and alert. The Slack post must still proceed regardless of email failure.
Gmail (report email)
Recipient address is invalid or bounces
Log the invalid address and the Gmail API error code. Remove the address from the active recipient list in config and alert the ops channel to update GMAIL_RECIPIENT_LIST_KEY. Do not retry a known-invalid address in the same run.
PagerDuty (alert creation)
Events API v2 returns 400 (invalid payload) or 429 (rate limited)
On 400: log the full request payload and the PagerDuty response body. Do not retry without fixing the payload. Alert support@gofullspec.com. On 429: retry after 60 seconds, then 120 seconds. If still failing after 2 retries, log the failure and post a manual escalation notice to SLACK_OPS_CHANNEL_ID stating the incident details so on-call staff can act without waiting for PagerDuty.
PagerDuty (alert creation)
Events API v2 is unreachable (network timeout or 5xx)
Retry 3 times with exponential backoff: 15 s, 45 s, 90 s. If all retries fail, post the full incident summary as a direct Slack message to the on-call contact defined in config (SLACK_ONCALL_USER_ID) and log the PagerDuty failure with timestamps. Never allow an unresolved incident to pass through without any escalation path.
Orchestration layer (any workflow)
Unhandled exception in any node not covered by the above scenarios
Catch-all error handler must be configured at the workflow level. On any uncaught exception: log the run ID, node name, exception type, stack trace, and input data. Post a generic failure alert to SLACK_OPS_CHANNEL_ID. Halt the current run. Never fail silently. Review logs within the next scheduled maintenance window.
All retry queues (notion_retry_queue, append_errors) must be reviewed weekly during the first month post-launch and monthly thereafter. Any entry older than 72 hours without resolution must trigger a manual review by the FullSpec team. Contact support@gofullspec.com if a retry queue is growing consistently.
Integration and API SpecPage 3 of 4
FS-DOC-05Technical
This document is maintained by FullSpec. For questions about any integration detail, scope requirement, or error behaviour defined here, contact support@gofullspec.com. Do not modify credential store keys or workflow trigger configurations without notifying the FullSpec team first.
Integration and API SpecPage 4 of 4

More documents for this process

Every document generated for End-of-day / Shift Handover.

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