FS-DOC-05Technical
Integration and API Spec
Audit Preparation Workflow
[YourCompany.com] · Legal Department · Prepared by FullSpec · [Today's Date]
This document is the authoritative technical reference for every integration point in the Audit Preparation Workflow automation. It covers the full tool inventory, exact OAuth scopes, webhook configurations, field-level mappings between agents, orchestration architecture, credential store layout, and defined error handling behaviour for every integration. The FullSpec team uses this specification as the build contract. No integration detail should be assumed or left to interpretation during build: if a value is not defined here it must be raised before the first line of configuration is written.
01Tool inventory
Tool
Role in automation
Auth method
Min plan required
Used by agent
Notion
Audit checklist database, status tracking, trigger source
OAuth 2.0 (internal integration token)
Notion Plus ($16/month)
Agent 1 (Evidence Collection), Agent 2 (Document Review)
Google Drive
Document storage, submission folder structure, evidence pack
OAuth 2.0 (service account + user delegation)
Google Workspace Business Starter ($12/month)
Agent 1 (Evidence Collection), Agent 2 (Document Review)
Gmail
Stakeholder assignment emails, overdue reminder emails
OAuth 2.0 (Gmail API scopes)
Google Workspace (included with Drive plan)
Agent 1 (Evidence Collection)
Slack
Internal overdue alerts, completion notifications to compliance channel
OAuth 2.0 (Slack app bot token)
Slack Pro (free tier sufficient for API; Pro for audit log access)
Agent 1 (Evidence Collection), Agent 2 (Document Review)
DocuSign
Declaration signature routing, completion webhook back to Notion
OAuth 2.0 (JWT grant / Authorization Code)
DocuSign Business Pro ($45/month)
Agent 2 (Document Review)
Orchestration layer
Hosts both agent workflows, manages scheduling, credential store, and retry logic
Internal (platform credential store, no external auth)
Paid plan supporting webhooks and scheduled polling
Both agents
Before you connect anything: all five external tool connections must be established and smoke-tested against sandbox or developer accounts before any production credentials are entered into the credential store. Notion integration tokens, Google service account keys, DocuSign JWT keys, and Slack bot tokens must each be validated in isolation before wiring agents together. Production credentials are entered only after the QA dry run described in the Test and QA Plan is passed.
02Per-tool integration detail
Notion
Acts as the system of record for audit records and evidence checklists. The automation reads audit records to trigger the Evidence Collection Agent and writes checklist item status updates throughout the cycle. The DocuSign completion webhook also writes back to Notion.
Auth method
OAuth 2.0 internal integration token. The integration is created at notion.so/my-integrations and connected to the audit workspace. Token is stored in the credential store as NOTION_API_TOKEN; never hardcoded.
Required scopes
read_content, update_content, insert_content, read_databases, query_databases. Scopes are granted at the integration level when the integration is shared with the target database pages.
Trigger setup
Notion does not emit native webhooks. The orchestration layer polls the Audits database on a 5-minute interval using the Databases > Query endpoint (POST /v1/databases/{DATABASE_ID}/query) with a filter on the status property equal to 'Confirmed' and last_edited_time greater than the previous poll timestamp. The DATABASE_ID for the Audits database and the DATABASE_ID for the Evidence Checklist database are stored in the credential store as NOTION_AUDIT_DB_ID and NOTION_CHECKLIST_DB_ID respectively.
Required configuration
Notion database schema must be finalised before build. Required properties on the Audits database: Name (title), Audit_Type (select), Engagement_Date (date), Compliance_Owner (person), Status (select: Draft, Confirmed, In Progress, Complete). Required properties on the Evidence Checklist database: Item_Name (title), Audit_ID (relation to Audits), Assigned_To (person), Due_Date (date), Status (select: Pending, Submitted, Verified, Overdue, Flagged), Drive_File_URL (url), Signature_Required (checkbox), DocuSign_Envelope_ID (text).
Rate limits
Notion API: 3 requests/second per integration token. At current volume (2 to 4 audit cycles/year, ~120 checklist items per cycle), peak load during a status update sweep is approximately 40 to 50 write requests per run. No throttling required; a 350 ms inter-request delay is sufficient to stay within limits.
Constraints
The integration token must be shared explicitly with every database page it needs to access. Notion does not support workspace-level API access for internal integrations. If new sub-pages are created during a cycle, the integration share must be updated manually or via the page-share API call included in the folder creation step.
// Trigger poll — Audits database
POST /v1/databases/{NOTION_AUDIT_DB_ID}/query
filter: { property: 'Status', select: { equals: 'Confirmed' } }
// Status update write — Checklist item
PATCH /v1/pages/{page_id}
properties: { Status: { select: { name: 'Verified' } }, Drive_File_URL: { url: '...' } }
// DocuSign webhook write-back
PATCH /v1/pages/{checklist_page_id}
properties: { Status: { select: { name: 'Verified' } }, DocuSign_Envelope_ID: { rich_text: [...] } }Google Drive
Stores all uploaded evidence documents and hosts the structured folder hierarchy per audit cycle. Agent 1 creates the folder structure on audit trigger. Agent 2 monitors the submission folder for new uploads and validates file metadata against the Notion checklist.
Auth method
OAuth 2.0 using a Google service account with domain-wide delegation. The service account JSON key is stored in the credential store as GOOGLE_SA_KEY_JSON. The service account impersonates the compliance manager's Google account for folder creation and permission assignment. User email is stored as GOOGLE_IMPERSONATION_EMAIL.
Required scopes
https://www.googleapis.com/auth/drive (full Drive access for folder creation and file management); https://www.googleapis.com/auth/drive.metadata.readonly (for file listing and metadata polling). If scope is restricted to per-folder, use https://www.googleapis.com/auth/drive.file scoped to the audit parent folder only.
Webhook / trigger setup
Google Drive supports push notifications via the Files: watch endpoint (POST https://www.googleapis.com/drive/v3/files/{fileId}/watch). A channel is registered on the submission folder with a TTL of 86400 seconds (24 hours) and must be renewed before expiry. The notification target is the orchestration layer's inbound webhook URL, stored as DRIVE_WEBHOOK_RECEIVER_URL. Because Drive webhooks do not carry file content, the notification triggers a subsequent Files: list call to retrieve the new file metadata. As a fallback, the orchestration layer also polls the submission folder every 15 minutes using Files: list with the query parameter 'parents in {FOLDER_ID} and trashed = false and modifiedTime > {last_poll_time}'.
Required configuration
Root audit evidence folder ID stored as DRIVE_AUDIT_ROOT_FOLDER_ID. Sub-folder naming convention agreed before build: {AuditType}_{YYYY}_{CycleRef}/Submissions/{Category}. Category list must be agreed and stored as a static lookup in the credential store or a Notion config page. Stakeholder upload permissions set to 'Commenter' or 'Editor' per folder; auditor read-only access granted only after pack is complete. Folder IDs created at runtime are written to Notion checklist properties, not hardcoded.
Rate limits
Google Drive API: 1,000 queries/100 seconds per user; 10,000 queries/100 seconds per project. At current volume, peak usage during a daily status sweep (120 files checked per cycle) is well within limits. No throttling required. Watch channel renewal must be scheduled reliably; a missed renewal causes a silent gap in webhook coverage, which the 15-minute polling fallback covers.
Constraints
Drive webhooks require a publicly reachable HTTPS endpoint with a valid TLS certificate. Self-signed certificates are rejected. The orchestration layer's webhook receiver URL must meet this requirement. Watch channels expire after a maximum of one week (604800 seconds) regardless of the TTL set; renewal logic is mandatory.
// Create submission folder
POST https://www.googleapis.com/drive/v3/files
{ name: '{AuditType}_{YYYY}_{CycleRef}', mimeType: 'application/vnd.google-apps.folder',
parents: [DRIVE_AUDIT_ROOT_FOLDER_ID] }
// Register watch channel on submission folder
POST https://www.googleapis.com/drive/v3/files/{folderId}/watch
{ id: '{uuid}', type: 'web_hook', address: DRIVE_WEBHOOK_RECEIVER_URL, expiration: now+86400000 }
// List new files (polling fallback)
GET https://www.googleapis.com/drive/v3/files
?q='{FOLDER_ID}'+in+parents+and+trashed=false+and+modifiedTime>'{last_poll}'
&fields=files(id,name,mimeType,modifiedTime,parents,size)Gmail
Sends personalised stakeholder assignment emails and overdue reminder emails on behalf of the compliance manager. All emails are sent via the Gmail API using the compliance manager's authenticated account so replies land in their inbox.
Auth method
OAuth 2.0 Authorization Code flow. The compliance manager authorises the integration once; the refresh token is stored in the credential store as GMAIL_REFRESH_TOKEN. Access tokens are refreshed automatically by the orchestration layer. Client ID and secret stored as GMAIL_CLIENT_ID and GMAIL_CLIENT_SECRET.
Required scopes
https://www.googleapis.com/auth/gmail.send (send messages on behalf of the user); https://www.googleapis.com/auth/gmail.compose (create draft messages for review before send, used during QA dry run only). The scope https://www.googleapis.com/auth/gmail.readonly is not required and must not be requested.
Webhook / trigger setup
Gmail is used as an action-only tool in this workflow. No inbound Gmail webhook is required. Outbound sends are triggered by the orchestration layer based on Notion checklist state (assignment step) and overdue status detection (reminder step).
Required configuration
Assignment email template stored as a parameterised string in the credential store key GMAIL_ASSIGNMENT_TEMPLATE. Reminder email template stored as GMAIL_REMINDER_TEMPLATE. Both templates use placeholders: {{stakeholder_name}}, {{document_list}}, {{due_date}}, {{drive_folder_link}}, {{audit_ref}}. From address is the compliance manager's verified Gmail address, stored as GMAIL_SENDER_ADDRESS. Reply-to is set to the same address.
Rate limits
Gmail API: 250 quota units/user/second; sending quota 2,000 messages/day for Workspace accounts. At current volume (120 stakeholder requests per audit cycle, up to 120 reminder emails per cycle), daily sends peak at approximately 240 messages on the assignment day and are well within the daily quota. No throttling required; a 200 ms inter-send delay is recommended as a best practice.
Constraints
The OAuth refresh token becomes invalid if the compliance manager revokes access or the Google account password is changed. A credential health check must be included in the monitoring runbook. Emails must not be sent to external auditor addresses from this automation; auditor notification is a human-executed step.
// Send assignment email
POST https://gmail.googleapis.com/gmail/v1/users/me/messages/send
{ raw: base64url(RFC2822 message) }
// Message headers
To: {stakeholder_email}
From: GMAIL_SENDER_ADDRESS
Subject: 'Action required: Audit evidence request [{audit_ref}]'
Body: GMAIL_ASSIGNMENT_TEMPLATE rendered with stakeholder context
// Overdue reminder — same endpoint, GMAIL_REMINDER_TEMPLATEIntegration and API SpecPage 1 of 4
FS-DOC-05Technical
Slack
Posts overdue alerts and cycle completion notifications to internal Slack channels. The bot posts to a compliance-specific channel for overdue items and a leadership channel for completion. No Slack messages are sent to external parties.
Auth method
OAuth 2.0 bot token (xoxb-). The Slack app is installed to the workspace once and the bot token is stored in the credential store as SLACK_BOT_TOKEN. No user-level OAuth is required. The app must be granted access to the target channels.
Required scopes
chat:write (post messages to channels the bot is a member of); chat:write.public (post to public channels without explicit membership, if compliance channel is public); users:read (resolve Slack user IDs from email addresses for @mention in overdue alerts); users:read.email (required alongside users:read for email-to-ID lookup).
Webhook / trigger setup
Slack is used as an action-only tool. No inbound Slack events or slash commands are required for this workflow. Messages are posted by the orchestration layer calling chat.postMessage. The compliance channel ID is stored as SLACK_COMPLIANCE_CHANNEL_ID and the leadership channel ID as SLACK_LEADERSHIP_CHANNEL_ID.
Required configuration
Slack app must be created at api.slack.com/apps and installed to the workspace. Bot must be added as a member to SLACK_COMPLIANCE_CHANNEL_ID and SLACK_LEADERSHIP_CHANNEL_ID before first run. Overdue alert message template stored as SLACK_OVERDUE_TEMPLATE with placeholders: {{stakeholder_slack_id}}, {{document_name}}, {{days_overdue}}, {{drive_folder_link}}. Completion message template stored as SLACK_COMPLETION_TEMPLATE.
Rate limits
Slack Web API: Tier 3 methods (chat.postMessage) allow 50 requests/minute per app. At current volume, maximum simultaneous overdue alerts per run is bounded by the 120 checklist items per cycle. No throttling required at this volume; a 300 ms delay between posts is sufficient. Slack recommends using Block Kit for formatted messages; templates should use Block Kit JSON.
Constraints
The users:read.email scope requires the admin to approve the scope during app installation. If this scope is not approved, the email-to-Slack-ID lookup step must be replaced with a static mapping table stored in Notion or the credential store. The bot token does not expire but must be rotated if the Slack app is reinstalled or the token is revoked.
// Post overdue alert
POST https://slack.com/api/chat.postMessage
Authorization: Bearer SLACK_BOT_TOKEN
{ channel: SLACK_COMPLIANCE_CHANNEL_ID,
blocks: [ rendered SLACK_OVERDUE_TEMPLATE with stakeholder context ] }
// Post completion alert
POST https://slack.com/api/chat.postMessage
{ channel: SLACK_LEADERSHIP_CHANNEL_ID,
blocks: [ rendered SLACK_COMPLETION_TEMPLATE with audit_ref and pack link ] }
// Email to Slack ID lookup
GET https://slack.com/api/users.lookupByEmail?email={stakeholder_email}
-> user.id used as {{stakeholder_slack_id}} in templateDocuSign
Routes declaration documents to nominated signatories when the Document Review Agent identifies that a checklist item has the Signature_Required flag set. DocuSign returns a completion webhook that the orchestration layer uses to update the Notion checklist item status to Verified.
Auth method
OAuth 2.0 JWT Grant (server-to-server, no user interaction required at runtime). The RSA private key is stored in the credential store as DOCUSIGN_RSA_PRIVATE_KEY. The integration key (client ID) is stored as DOCUSIGN_INTEGRATION_KEY. The impersonated user GUID (compliance manager's DocuSign account) is stored as DOCUSIGN_IMPERSONATION_GUID. JWT tokens are generated by the orchestration layer and exchanged for access tokens at the DocuSign token endpoint.
Required scopes
signature (create and send envelopes); impersonation (required for JWT grant to act on behalf of the DocuSign user). Both scopes must be granted in the DocuSign admin console under Apps and Keys before the integration can send envelopes.
Webhook / trigger setup
DocuSign Connect (webhook) is configured at the account level or per-envelope to deliver envelope status change events to the orchestration layer's inbound webhook URL, stored as DOCUSIGN_CONNECT_RECEIVER_URL. The event types subscribed are: envelope-completed, envelope-declined, envelope-voided. The HMAC signature header (X-DocuSign-Signature-1) must be validated against DOCUSIGN_CONNECT_HMAC_KEY on every inbound request before processing. Unvalidated requests must be rejected with HTTP 401.
Required configuration
DocuSign template IDs for each declaration document type are stored in the credential store as a JSON object under key DOCUSIGN_TEMPLATE_MAP (e.g. {"director_declaration": "tmpl_id_1", "data_handling_declaration": "tmpl_id_2"}). Signatory roles and tab definitions are configured within each DocuSign template; the automation passes recipient name and email at envelope creation time. The DocuSign account base URL is stored as DOCUSIGN_BASE_URL (e.g. https://na4.docusign.net/restapi). Account ID stored as DOCUSIGN_ACCOUNT_ID.
Rate limits
DocuSign Business Pro: 1,000 API calls/hour; sending limit governed by plan envelope allowance (300 envelopes/month on Business Pro). At current volume (2 to 4 audit cycles/year, estimated 10 to 20 signature requests per cycle), annual envelope usage is 20 to 80 envelopes, well within the monthly allowance. No throttling required.
Constraints
JWT grant requires the DocuSign admin to explicitly grant consent for the integration key before the first envelope can be sent. This is a one-time step done via the DocuSign OAuth consent URL and must be completed during the Connect phase. Templates must be created and saved in the DocuSign account before the Document Review Agent build begins; template IDs cannot be determined until templates exist.
// Create and send envelope from template
POST {DOCUSIGN_BASE_URL}/v2.1/accounts/{DOCUSIGN_ACCOUNT_ID}/envelopes
Authorization: Bearer {access_token}
{ status: 'sent',
templateId: DOCUSIGN_TEMPLATE_MAP[document_type],
templateRoles: [{ roleName: 'Signatory', name: recipient_name, email: recipient_email }] }
// Inbound Connect webhook payload (envelope-completed)
POST DOCUSIGN_CONNECT_RECEIVER_URL
Headers: X-DocuSign-Signature-1: {hmac_signature}
Body: { envelopeId, status: 'completed', completedDateTime, envelopeSummary: {...} }
// Validate HMAC before processing
HMAC-SHA256(request_body, DOCUSIGN_CONNECT_HMAC_KEY) == X-DocuSign-Signature-103Field mappings between tools
The tables below define every field-level mapping across agent handoffs. Use exact property names as shown; any deviation from the Notion schema column names or Drive metadata field names will cause mapping errors at runtime.
Handoff 1: Notion Audits database to Evidence Collection Agent (audit trigger to checklist generation and assignment emails)
Source tool
Source field
Destination tool
Destination field
Notion
`Audits.Name`
Notion
`Checklist.Audit_ID` (relation)
Notion
`Audits.Audit_Type`
Notion
`Checklist.Item_Name` (pre-populated per type)
Notion
`Audits.Engagement_Date`
Notion
`Checklist.Due_Date`
Notion
`Audits.Compliance_Owner`
Gmail
`message.from` (sender address)
Notion
`Audits.Audit_Type`
Gmail
`message.subject` (audit ref inserted)
Notion
`Checklist.Assigned_To` (person email)
Gmail
`message.to`
Notion
`Checklist.Item_Name`
Gmail
`message.body` (via GMAIL_ASSIGNMENT_TEMPLATE `{{document_list}}`)
Notion
`Checklist.Due_Date`
Gmail
`message.body` (via template `{{due_date}}`)
Google Drive
`file.webViewLink` (new submission folder)
Gmail
`message.body` (via template `{{drive_folder_link}}`)
Google Drive
`file.id` (submission folder)
Notion
`Checklist.Drive_File_URL` (folder link)
Handoff 2: Google Drive upload event to Document Review and Organisation Agent (file validation and Notion status update)
Source tool
Source field
Destination tool
Destination field
Google Drive
`file.name`
Notion
`Checklist.Item_Name` (matched by naming convention)
Google Drive
`file.id`
Notion
`Checklist.Drive_File_URL`
Google Drive
`file.mimeType`
Notion
`Checklist.Status` (set to Flagged if mimeType unexpected)
Google Drive
`file.modifiedTime`
Notion
`Checklist.Status` (Overdue evaluated against Due_Date)
Google Drive
`file.parents[0]`
Notion
`Checklist.Audit_ID` (resolved via DRIVE_AUDIT_ROOT_FOLDER_ID mapping)
Notion
`Checklist.Signature_Required`
DocuSign
`envelope.templateRoles[0].email` (routes if true)
Notion
`Checklist.Assigned_To` (person name)
DocuSign
`envelope.templateRoles[0].name`
Notion
`Checklist.Item_Name`
DocuSign
`envelope.templateId` (resolved via DOCUSIGN_TEMPLATE_MAP)
Handoff 3: DocuSign completion webhook to Notion and Slack (signature confirmation and cycle completion alert)
Source tool
Source field
Destination tool
Destination field
DocuSign
`envelopeId`
Notion
`Checklist.DocuSign_Envelope_ID`
DocuSign
`status` (= 'completed')
Notion
`Checklist.Status` (set to Verified)
DocuSign
`completedDateTime`
Notion
`Checklist.Drive_File_URL` (signed copy URL written after download)
Notion
`Checklist.Status` (all = Verified)
Slack
`chat.postMessage.channel` = SLACK_LEADERSHIP_CHANNEL_ID
Notion
`Audits.Name`
Slack
`blocks[].text` (via SLACK_COMPLETION_TEMPLATE `{{audit_ref}}`)
Google Drive
`file.webViewLink` (final evidence pack folder)
Slack
`blocks[].text` (via template `{{pack_link}}`)
Integration and API SpecPage 2 of 4
FS-DOC-05Technical
04Build stack and orchestration
Orchestration layout
Two discrete workflows are built on the automation platform: one per agent. Workflow 1 (Evidence Collection Agent) owns the Notion poll trigger, checklist generation, Gmail sends, Drive folder creation, daily status monitoring loop, and Slack/Gmail overdue alerts. Workflow 2 (Document Review and Organisation Agent) owns the Drive webhook/poll trigger, file validation logic, Notion status writes, DocuSign envelope creation, DocuSign webhook receiver, folder organisation moves, and Slack completion alert. Both workflows share a single credential store instance. No credentials are passed between workflows as runtime variables; each workflow reads directly from the store by key.
Agent 1 trigger mechanism
Poll-based. The orchestration layer queries the Notion Audits database (POST /v1/databases/{NOTION_AUDIT_DB_ID}/query) on a 5-minute schedule. The query filters for records where Status = 'Confirmed' and last_edited_time is greater than the last successful poll timestamp, which is persisted in the workflow state. This avoids reprocessing already-triggered audits. A deduplication key based on the Notion page ID is checked before any downstream action fires.
Agent 1 daily monitoring loop
A second scheduled trigger runs once per day at 08:00 in the compliance manager's local timezone. It queries all Checklist items related to in-progress audits, compares Due_Date against today's date, and sets Status to Overdue for any item where Status = Pending and Due_Date is in the past. Overdue items trigger the Slack alert and Gmail reminder branches within the same workflow run.
Agent 2 trigger mechanism
Webhook-primary with polling fallback. The primary trigger is the Google Drive Files: watch notification delivered to DRIVE_WEBHOOK_RECEIVER_URL. The X-Goog-Channel-ID header is validated against the registered channel ID stored in workflow state. If the header does not match, the request is discarded. As a fallback, a 15-minute scheduled poll queries the Drive submission folder using Files: list. Results from both paths feed into the same file-processing branch, with a deduplication check on file.id to prevent double-processing.
DocuSign webhook signature validation
Every inbound POST to DOCUSIGN_CONNECT_RECEIVER_URL is validated before processing. The orchestration layer computes HMAC-SHA256 of the raw request body using DOCUSIGN_CONNECT_HMAC_KEY and compares the result to the X-DocuSign-Signature-1 header value. A mismatch returns HTTP 401 and logs the event. Processing proceeds only on a valid match.
Drive watch channel renewal
A scheduled job runs every 20 hours to renew the Drive watch channel by calling Files: watch again with the same channel ID. The new expiration timestamp is written to workflow state. If the renewal call fails, an alert is posted to SLACK_COMPLIANCE_CHANNEL_ID and the 15-minute polling fallback continues to operate until the channel is renewed successfully.
Credential store type
The automation platform's native encrypted credential store is used for all secrets. No secrets are stored in workflow logic, environment files, or Notion pages. All keys listed in the credential store block below are referenced by name in workflow steps.
Credential store contents (all keys stored as encrypted secrets in the automation platform)
// Notion
NOTION_API_TOKEN = <internal integration token from notion.so/my-integrations>
NOTION_AUDIT_DB_ID = <Notion database ID for Audits database>
NOTION_CHECKLIST_DB_ID = <Notion database ID for Evidence Checklist database>
// Google (Drive + Gmail)
GOOGLE_SA_KEY_JSON = <service account JSON key file contents, base64-encoded>
GOOGLE_IMPERSONATION_EMAIL = <compliance manager Google Workspace email address>
GMAIL_CLIENT_ID = <OAuth 2.0 client ID from Google Cloud Console>
GMAIL_CLIENT_SECRET = <OAuth 2.0 client secret>
GMAIL_REFRESH_TOKEN = <long-lived refresh token from compliance manager OAuth flow>
GMAIL_SENDER_ADDRESS = <compliance manager Gmail address>
DRIVE_AUDIT_ROOT_FOLDER_ID = <Google Drive folder ID of the top-level audit evidence folder>
DRIVE_WEBHOOK_RECEIVER_URL = <public HTTPS URL of the orchestration layer webhook endpoint>
// Slack
SLACK_BOT_TOKEN = <xoxb- bot token from Slack app settings>
SLACK_COMPLIANCE_CHANNEL_ID = <channel ID of the internal compliance Slack channel>
SLACK_LEADERSHIP_CHANNEL_ID = <channel ID of the leadership notification channel>
// DocuSign
DOCUSIGN_INTEGRATION_KEY = <DocuSign app integration key (client ID)>
DOCUSIGN_RSA_PRIVATE_KEY = <RSA private key PEM for JWT grant, newlines escaped>
DOCUSIGN_IMPERSONATION_GUID = <DocuSign user GUID of the compliance manager account>
DOCUSIGN_ACCOUNT_ID = <DocuSign account ID>
DOCUSIGN_BASE_URL = <DocuSign REST API base URL e.g. https://na4.docusign.net/restapi>
DOCUSIGN_CONNECT_RECEIVER_URL = <public HTTPS URL of the DocuSign Connect webhook endpoint>
DOCUSIGN_CONNECT_HMAC_KEY = <HMAC secret configured in DocuSign Connect settings>
DOCUSIGN_TEMPLATE_MAP = <JSON object mapping document type keys to template IDs>
// Gmail templates
GMAIL_ASSIGNMENT_TEMPLATE = <parameterised RFC2822 body string with placeholders>
GMAIL_REMINDER_TEMPLATE = <parameterised RFC2822 body string with placeholders>
// Slack templates
SLACK_OVERDUE_TEMPLATE = <Block Kit JSON string with placeholders>
SLACK_COMPLETION_TEMPLATE = <Block Kit JSON string with placeholders>
All credential store keys must be populated before the first workflow activation. Any key left empty will cause the affected workflow step to throw an unhandled credential error at runtime. Run the credential validation checklist from the Developer Handover Pack (FS-DOC-04) immediately after populating the store and before any QA dry run begins.
Integration and API SpecPage 3 of 4
FS-DOC-05Technical
05Error handling and retry logic
Every integration point has a defined failure behaviour. Unhandled exceptions must never fail silently. All errors must be logged to the orchestration platform's execution log with a timestamp, the failing step name, the HTTP status code or error type, and the input payload that caused the failure. Where a retry is defined, exponential backoff applies unless stated otherwise.
Integration
Scenario
Required behaviour
Notion (poll trigger)
API returns HTTP 429 (rate limited)
Pause workflow execution for 2 seconds and retry up to 3 times with exponential backoff (2s, 4s, 8s). If all retries fail, log the error and skip the current poll cycle. The next scheduled poll will resume normally. Do not alert on a single failed poll cycle; alert only after 3 consecutive failed cycles.
Notion (status write)
API returns HTTP 404 (page not found)
The Notion checklist page ID is invalid or the page was deleted. Log the error with the page ID and halt processing for that checklist item only. Post an alert to SLACK_COMPLIANCE_CHANNEL_ID with the audit reference and the item name so the compliance manager can investigate. Do not retry; the page must be recreated manually.
Notion (status write)
API returns HTTP 500 or HTTP 503
Retry up to 3 times with exponential backoff (5s, 10s, 20s). If all retries fail, log the full response and queue the write for the next execution cycle. Do not discard the write payload; it must be persisted in workflow state until it succeeds or is manually cleared.
Google Drive (watch channel)
Watch channel expires without renewal
The 20-hour renewal job is the primary guard. If the renewal POST returns a non-2xx response, retry once after 60 seconds. If the second attempt fails, post an alert to SLACK_COMPLIANCE_CHANNEL_ID. The 15-minute polling fallback takes over automatically and must remain active until the watch channel is restored. Log all polling events during the fallback period.
Google Drive (file validation)
Uploaded file has unexpected MIME type or naming convention mismatch
Set Notion Checklist item Status to Flagged. Do not move the file to the verified folder. Post an alert to SLACK_COMPLIANCE_CHANNEL_ID with the file name, file ID, Drive link, and the expected naming pattern. The compliance manager reviews and either renames and re-uploads or manually marks the item as Verified in Notion. The automation does not auto-reject files.
Gmail (send)
OAuth refresh token is invalid or revoked
The send step returns HTTP 401. Do not retry. Log the error and post an immediate alert to SLACK_COMPLIANCE_CHANNEL_ID with the message that Gmail authorisation has expired and must be re-authenticated. Queue all pending email sends in workflow state. The FullSpec team must guide re-authorisation via the OAuth flow before queued sends are released.
Gmail (send)
API returns HTTP 429 or daily quota exceeded
Retry with a 60-second delay for HTTP 429. If the daily quota (2,000 messages/day) is exceeded, halt all remaining sends for the day, log the quota event, and post an alert to SLACK_COMPLIANCE_CHANNEL_ID. Schedule remaining sends to begin at 00:01 the following day when the quota resets.
Slack (chat.postMessage)
API returns HTTP 400 with error 'channel_not_found'
The configured channel ID is invalid or the bot is not a member. Log the error with the channel ID. Do not retry. Post a fallback alert to any other reachable Slack channel the bot is a member of, or if none, send a Gmail notification to GMAIL_SENDER_ADDRESS as a manual fallback. This must not fail silently.
DocuSign (envelope creation)
JWT grant fails (401 consent_required)
DocuSign admin consent has not been granted for the integration key. Do not retry automatically. Log the error and post an alert to SLACK_COMPLIANCE_CHANNEL_ID with the DocuSign consent URL and instructions. All signature-required checklist items remain in Pending status until consent is granted and the envelope creation is re-triggered manually.
DocuSign (envelope creation)
Template ID not found in DOCUSIGN_TEMPLATE_MAP for document type
The document type key from the Notion checklist item does not match any key in DOCUSIGN_TEMPLATE_MAP. Log the unmatched key and set the Notion item Status to Flagged. Post an alert to SLACK_COMPLIANCE_CHANNEL_ID identifying the checklist item and the unmatched document type. Do not create a blank envelope. The compliance manager must route the signature request manually and update DOCUSIGN_TEMPLATE_MAP to prevent recurrence.
DocuSign (Connect webhook)
Inbound webhook HMAC validation fails
Reject the request immediately with HTTP 401. Log the source IP, timestamp, and raw headers. Do not process the payload. If more than 3 validation failures occur within 10 minutes, post an alert to SLACK_COMPLIANCE_CHANNEL_ID flagging a possible misconfiguration or unauthorised request. The FullSpec team must investigate before re-enabling webhook processing.
Orchestration layer (any step)
Unhandled exception or unexpected error type
The workflow execution must be halted at the failing step, not allowed to continue with incomplete data. The full execution context, input payload, and stack trace must be written to the platform execution log. A Slack alert must be posted to SLACK_COMPLIANCE_CHANNEL_ID with the workflow name, step name, error message, and a link to the execution log. No exception may fail silently. If Slack is also unavailable, the platform's native email error notification must be enabled as a secondary alert channel.
For all error scenarios marked in red above, the compliance manager or the FullSpec team must be notified before the next workflow execution cycle runs. These are not self-healing conditions and must not be left unresolved across multiple execution cycles. Contact support@gofullspec.com if any integration error cannot be resolved using the information in this document.
Integration and API SpecPage 4 of 4