Back to Regulatory Change Monitoring

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

Regulatory Change Monitoring

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

This document defines every integration point in the Regulatory Change Monitoring automation: the tools connected, the exact authentication and scope requirements for each, the field mappings that pass data between agents, the orchestration layout, and the error handling behaviour required at every failure point. It is written for the FullSpec build team and assumes direct access to all credential stores and platform configuration panels. Nothing in this document is owner-facing. Where a configuration decision requires a business input (such as a routing table value or a relevance threshold), the required variable name is stated so it can be resolved before build begins.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agents
Feedly
Aggregates regulatory RSS and web feeds; primary content source
OAuth 2.0 (Authorization Code flow)
Feedly Pro+ ($18/mo)
Agent 1: Source Monitor Agent
Airtable
Compliance change register; routing table; deduplication store
Personal Access Token (PAT) with base-level scope
Airtable Plus ($20/mo per seat)
Agent 1, Agent 2, Agent 3
Notion
Summary document store; team knowledge base; AI classification context
OAuth 2.0 (Internal Integration Token)
Notion Plus ($16/mo)
Agent 2: Relevance and Summary Agent
Slack
Real-time owner alerts by topic channel; overdue follow-up messages
OAuth 2.0 (Bot Token via Slack App)
Slack Free (no cost; webhooks available)
Agent 3: Alert and Digest Agent
Gmail
Weekly digest email to compliance lead and management recipients
OAuth 2.0 (Google Workspace; service account or user delegation)
Google Workspace (no add-on cost)
Agent 3: Alert and Digest Agent
Automation platform
Orchestration layer; hosts all agent workflows, schedules, credential store, and retry logic
Platform-native credential vault
Platform Standard tier ($49/mo)
All agents
Before you connect anything: provision sandbox or developer-tier accounts for every tool in the table above. Validate each connection end-to-end in a non-production environment before any production credentials are entered into the credential store. Production credentials must never be hardcoded in workflow logic or committed to version control.

02Per-tool integration detail

Feedly

Feedly is the feed aggregation layer for the Source Monitor Agent. It holds all configured regulatory RSS feeds and monitored web sources. The automation polls the Feedly Streams API to retrieve new articles since the last fetch timestamp. Custom web watchers (for sources without RSS) are configured as Feedly Board integrations where supported, or handled via scraper fallback documented separately.

Auth method
OAuth 2.0 Authorization Code flow. Client ID and Client Secret stored in credential store as FEEDLY_CLIENT_ID and FEEDLY_CLIENT_SECRET. Access token stored as FEEDLY_ACCESS_TOKEN; refresh token stored as FEEDLY_REFRESH_TOKEN. Token refresh handled automatically by the orchestration layer on 401 responses.
Required scopes
https://cloud.feedly.com/subscriptions (read), https://cloud.feedly.com/streams (read), https://cloud.feedly.com/markers (read/write for marking items as read after processing)
Webhook / trigger setup
Feedly does not natively push webhooks on the Pro+ plan. The Source Monitor Agent uses a scheduled poll: GET /v3/streams/contents?streamId={FEEDLY_STREAM_ID}&count=50&unreadOnly=true&newerThan={LAST_RUN_TIMESTAMP}. LAST_RUN_TIMESTAMP is stored in the credential/config store and updated after each successful run.
Required configuration
FEEDLY_STREAM_ID must be set to the team's curated regulatory collection stream ID (retrieved via GET /v3/collections after setup). FEEDLY_BOARD_IDS may be set as a comma-separated list for additional board streams. All IDs stored in credential store; none hardcoded in workflow nodes.
Rate limits
Feedly Pro+ allows 250 API calls per day. At one poll per day fetching up to 50 items, current volume (40 to 80 sources per month, approximately 2 to 4 items per source per month) sits well within limits. No throttling logic is required at current volume. Monitor if source count exceeds 150.
Constraints
Items behind login or paywalled sources cannot be fetched via the Feedly API. These sources require separate scraper logic or manual addition. The API returns a maximum of 1000 items per stream per call; this limit is not a concern at current volume.
// Input
GET /v3/streams/contents
  streamId: {FEEDLY_STREAM_ID}
  count: 50
  unreadOnly: true
  newerThan: {LAST_RUN_TIMESTAMP}
// Output
items[]: { id, title, originId, origin.title, published, summary.content, alternate[0].href, author }
Airtable

Airtable serves as the compliance change register, the deduplication store, and the topic-to-owner routing table. Three tables are required within one base: tbl_register (primary log), tbl_routing (owner routing rules), and tbl_dedup (processed item ID store). All three must be created with the schema defined in the Developer Handover Pack before build begins.

Auth method
Personal Access Token (PAT). Token stored in credential store as AIRTABLE_PAT. Passed in Authorization header as Bearer {AIRTABLE_PAT} on all requests.
Required scopes
data.records:read, data.records:write, schema.bases:read. Scopes selected at PAT creation in the Airtable developer portal. Assign the PAT to a dedicated service account, not a personal user account.
Webhook / trigger setup
Agent 3 (Alert and Digest Agent) uses the Airtable Webhooks API to subscribe to record creation events on tbl_register. Webhook endpoint: POST /v0/bases/{AIRTABLE_BASE_ID}/webhooks. Payload signing secret stored as AIRTABLE_WEBHOOK_SECRET. The orchestration layer must validate the X-Airtable-Client-Secret header on every inbound webhook before processing.
Required configuration
AIRTABLE_BASE_ID: the target base ID (found in the base URL). AIRTABLE_REGISTER_TABLE_ID: ID of tbl_register. AIRTABLE_ROUTING_TABLE_ID: ID of tbl_routing. AIRTABLE_DEDUP_TABLE_ID: ID of tbl_dedup. All stored in credential store. The routing table must be pre-populated with topic categories and Slack channel/user mappings before Agent 3 build begins.
Rate limits
Airtable REST API: 5 requests per second per base. At current volume (estimated 5 to 15 new records per day), this limit is not approached. No throttling needed. The Webhooks API fires immediately on record creation; no polling is required for Agent 3.
Constraints
Airtable field names are case-sensitive and must match exactly the field names in the workflow field-mapping nodes. Any schema changes to tbl_register after build must be reflected in all workflow nodes referencing those fields. Attachment fields cannot be written via the standard REST API without a separate upload step.
// Input (record creation, Agent 1 and 2)
POST /v0/{AIRTABLE_BASE_ID}/{AIRTABLE_REGISTER_TABLE_ID}
  fields: { item_id, source_name, source_url, published_date,
            effective_date, topic_category, relevance_score,
            plain_summary, suggested_owner, status }
// Input (dedup check, Agent 1)
GET /v0/{AIRTABLE_BASE_ID}/{AIRTABLE_DEDUP_TABLE_ID}
  filterByFormula: {item_id}='{feedly_item_id}'
// Output (routing lookup, Agent 3)
GET /v0/{AIRTABLE_BASE_ID}/{AIRTABLE_ROUTING_TABLE_ID}
  filterByFormula: {topic_category}='{classified_topic}'
  -> fields: { slack_channel, slack_user_id, owner_email }
Notion

Notion is used by the Relevance and Summary Agent to store plain-language summary documents and to provide topic classification context (keyword lists, jurisdiction definitions, and scoring rules stored as a Notion database). The automation reads the classification ruleset from a designated Notion database and writes summary documents as child pages under a configured parent page.

Auth method
Notion Internal Integration Token. Created at notion.so/my-integrations and shared with the target workspace pages and databases. Token stored in credential store as NOTION_TOKEN. Passed as Authorization: Bearer {NOTION_TOKEN} and Notion-Version: 2022-06-28 headers on all requests.
Required scopes
Read content (pages and databases the integration is shared with), Insert content (create child pages), Update content (patch page properties). Notion integrations use capability flags, not OAuth scope strings: set Read content, Insert content, and Update content to enabled in the integration settings.
Webhook / trigger setup
Notion does not support outbound webhooks. Agent 2 reads from Notion on each invocation (pulled by the orchestration layer when a new Feedly item is passed downstream). No inbound webhook configuration required.
Required configuration
NOTION_CLASSIFICATION_DB_ID: the database ID containing the jurisdiction/topic keyword ruleset. NOTION_SUMMARY_PARENT_PAGE_ID: the page ID under which new summary child pages are created. NOTION_API_VERSION: set to 2022-06-28. All stored in credential store. The classification database must be structured with columns: topic_keyword (title), jurisdiction, relevance_weight, owner_tag before Agent 2 build begins.
Rate limits
Notion API: 3 requests per second average; burst up to 90 requests per minute. At current volume (5 to 15 classifications per day), this limit is not approached. No throttling needed.
Constraints
Notion page IDs and database IDs must be extracted from the page URL (format: 32-character hex string). The integration must be explicitly shared with every page and database it needs to access; access is not inherited from a parent page by default. Rich-text blocks are returned as arrays; the workflow must flatten these to a plain string before passing to downstream tools.
// Input (classification ruleset read, Agent 2)
GET /v1/databases/{NOTION_CLASSIFICATION_DB_ID}/query
  -> rows[]: { topic_keyword, jurisdiction, relevance_weight, owner_tag }
// Input (summary page creation, Agent 2)
POST /v1/pages
  parent: { page_id: {NOTION_SUMMARY_PARENT_PAGE_ID} }
  properties: { title: { title: [{ text: { content: item_title } }] } }
  children: [ paragraph block with plain_summary text ]
// Output
  -> created page: { id, url, created_time }
Integration and API SpecPage 1 of 3
FS-DOC-05Technical
Slack

Slack is used by the Alert and Digest Agent to post real-time structured alerts to topic-specific channels and to tag the responsible owner directly. Overdue follow-up reminders are also sent via Slack if an action item has not been acknowledged within the configured number of days. A dedicated Slack App must be created in the workspace before build.

Auth method
OAuth 2.0 Bot Token. A Slack App is created at api.slack.com/apps, installed to the workspace, and the Bot Token (xoxb-...) is stored in the credential store as SLACK_BOT_TOKEN. The App must be invited to each alert channel before it can post.
Required scopes
chat:write (post messages to channels the bot is a member of), chat:write.public (post to public channels without prior membership, optional), channels:read (enumerate channel list for routing validation), users:read (look up user ID by email for owner tagging), users:read.email (required alongside users:read for email-based lookup)
Webhook / trigger setup
Outbound only at current build scope. No inbound Slack events are consumed. If future builds require acknowledgement tracking, the Slack Events API can be enabled on the App with the message.channels event subscription and a registered request URL on the orchestration layer. Signature validation uses SLACK_SIGNING_SECRET stored in credential store.
Required configuration
SLACK_BOT_TOKEN: bot OAuth token. SLACK_SIGNING_SECRET: used for future event validation. SLACK_DEFAULT_CHANNEL: fallback channel ID if routing table returns no match (e.g. C012AB3CD). Channel IDs (not names) for each topic area must be stored in tbl_routing in Airtable, not hardcoded in workflow nodes. SLACK_OVERDUE_REMINDER_DAYS: number of days before a follow-up reminder fires, stored as a config variable (default: 5).
Rate limits
Slack Web API: Tier 3 for chat.postMessage, allowing approximately 50 requests per minute. At current volume (5 to 15 alerts per day plus a weekly digest), this limit is not approached. No throttling needed.
Constraints
The Bot Token user must be invited to private channels before posting. Block Kit message payloads have a maximum size of 3001 characters per block; summaries must be truncated if they exceed this. Slack channel IDs, not display names, must be used in all API calls to avoid breakage if a channel is renamed.
// Input (alert post, Agent 3)
POST /api/chat.postMessage
  channel: {slack_channel_id}  // from tbl_routing
  blocks: [
    { type: header, text: item_title }
    { type: section, text: plain_summary }
    { type: context, elements: [ source_name, effective_date, relevance_score ] }
    { type: actions, elements: [ Acknowledge button -> airtable record URL ] }
  ]
  text: fallback plain text for notification previews
// Output
  -> { ok: true, ts: message_timestamp, channel: channel_id }
Gmail

Gmail is used by the Alert and Digest Agent to send the weekly compliance digest email to the compliance lead and any configured management recipients. The email is assembled from all Airtable records created in the previous seven days and formatted using a stored HTML template. Overdue action reminders may also be sent by email as a secondary channel alongside Slack.

Auth method
OAuth 2.0 via the Google API. A Google Cloud project is required with the Gmail API enabled. For a single sending account, use a service account with domain-wide delegation, or a standard OAuth 2.0 user credential with offline access. Credentials stored as GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET, GMAIL_REFRESH_TOKEN. The sending address is stored as GMAIL_SENDER_ADDRESS.
Required scopes
https://www.googleapis.com/auth/gmail.send (send-only; do not request broader mail scopes unless read access is explicitly required by a future build step). If using a service account with domain-wide delegation, the scope must be granted at the Google Workspace admin console level.
Webhook / trigger setup
Send-only integration; no inbound webhook or Gmail push notification is configured in this build. The weekly digest is triggered by a Monday 08:00 schedule on the orchestration layer, not by Gmail events.
Required configuration
GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET, GMAIL_REFRESH_TOKEN: stored in credential store. GMAIL_SENDER_ADDRESS: the From address (e.g. compliance-monitor@yourcompany.com). GMAIL_DIGEST_RECIPIENTS: comma-separated list of To addresses stored as a config variable. GMAIL_DIGEST_TEMPLATE_ID: reference key for the HTML template stored in the orchestration layer's template store (not hardcoded inline). Template placeholders: {{week_start_date}}, {{week_end_date}}, {{items_count}}, {{items_table_html}}, {{digest_footer}}.
Rate limits
Gmail API send quota: 100 emails per second per user (effectively unlimited at this volume). Daily sending limit for Google Workspace accounts: 2000 messages per day. The digest is one email per week; overdue reminders add at most 15 per day. No throttling needed.
Constraints
The Gmail API requires messages to be RFC 2822 compliant and base64url-encoded before submission via the messages.send endpoint. HTML email content must include a plain-text alternative part to avoid spam classification. OAuth refresh tokens expire if the account is inactive for 6 months; a token-refresh health check should run monthly.
// Input (digest send, Agent 3)
POST /gmail/v1/users/{GMAIL_SENDER_ADDRESS}/messages/send
  raw: base64url_encoded_RFC2822_message
    To: {GMAIL_DIGEST_RECIPIENTS}
    From: {GMAIL_SENDER_ADDRESS}
    Subject: Weekly Compliance Digest: {week_start_date} to {week_end_date}
    Content-Type: multipart/alternative
      text/plain: plain digest body
      text/html: rendered HTML from GMAIL_DIGEST_TEMPLATE_ID
// Output
  -> { id: message_id, threadId, labelIds: ['SENT'] }

03Field mappings between tools

The tables below document every field handoff between agents and tools. Field names are shown in exact monospace form as they must appear in the workflow mapping nodes. Any rename between source and destination is explicit in the Destination field column.

Handoff 1: Feedly to Airtable tbl_dedup and tbl_register (Source Monitor Agent, Agent 1)

Source tool
Source field
Destination tool
Destination field
Feedly
`items[].id`
Airtable tbl_dedup
`item_id`
Feedly
`items[].title`
Airtable tbl_register
`item_title`
Feedly
`items[].origin.title`
Airtable tbl_register
`source_name`
Feedly
`items[].alternate[0].href`
Airtable tbl_register
`source_url`
Feedly
`items[].published`
Airtable tbl_register
`published_date`
Feedly
`items[].summary.content`
Airtable tbl_register
`raw_content`
Feedly
`items[].id`
Airtable tbl_register
`item_id`

Handoff 2: Airtable tbl_register to Notion (Relevance and Summary Agent, Agent 2 read)

Source tool
Source field
Destination tool
Destination field
Airtable tbl_register
`item_id`
Notion summary page
`page.properties.item_id`
Airtable tbl_register
`item_title`
Notion summary page
`page.properties.title[0].text.content`
Airtable tbl_register
`raw_content`
Notion summary page
`page.children[0].paragraph.text[0].text.content`
Airtable tbl_register
`source_name`
Notion summary page
`page.children[1].paragraph.text[0].text.content`
Airtable tbl_register
`published_date`
Notion summary page
`page.properties.published_date.date.start`

Handoff 3: Relevance and Summary Agent output back to Airtable tbl_register (Agent 2 write)

Source tool
Source field
Destination tool
Destination field
Agent 2 output
`relevance_score`
Airtable tbl_register
`relevance_score`
Agent 2 output
`plain_summary`
Airtable tbl_register
`plain_summary`
Agent 2 output
`effective_date`
Airtable tbl_register
`effective_date`
Agent 2 output
`topic_category`
Airtable tbl_register
`topic_category`
Agent 2 output
`suggested_owner`
Airtable tbl_register
`suggested_owner`
Agent 2 output
`status`
Airtable tbl_register
`status`
Notion page
`page.url`
Airtable tbl_register
`notion_page_url`

Handoff 4: Airtable tbl_register and tbl_routing to Slack (Alert and Digest Agent, Agent 3)

Source tool
Source field
Destination tool
Destination field
Airtable tbl_register
`item_title`
Slack Block Kit
`blocks[0].text.text`
Airtable tbl_register
`plain_summary`
Slack Block Kit
`blocks[1].text.text`
Airtable tbl_register
`source_name`
Slack Block Kit
`blocks[2].elements[0].text`
Airtable tbl_register
`effective_date`
Slack Block Kit
`blocks[2].elements[1].text`
Airtable tbl_register
`relevance_score`
Slack Block Kit
`blocks[2].elements[2].text`
Airtable tbl_routing
`slack_channel`
Slack API
`channel`
Airtable tbl_routing
`slack_user_id`
Slack Block Kit
`blocks[1].text.text` (mention prefix)

Handoff 5: Airtable tbl_register to Gmail digest (Alert and Digest Agent, Agent 3)

Source tool
Source field
Destination tool
Destination field
Airtable tbl_register
`item_title`
Gmail HTML template
`{{item_title}}`
Airtable tbl_register
`plain_summary`
Gmail HTML template
`{{item_summary}}`
Airtable tbl_register
`source_name`
Gmail HTML template
`{{item_source}}`
Airtable tbl_register
`effective_date`
Gmail HTML template
`{{item_effective_date}}`
Airtable tbl_register
`topic_category`
Gmail HTML template
`{{item_topic}}`
Airtable tbl_register
`notion_page_url`
Gmail HTML template
`{{item_detail_link}}`
Config variable
`GMAIL_DIGEST_RECIPIENTS`
Gmail API
`To` header
Integration and API SpecPage 2 of 3
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
One workflow per agent: Workflow 1 (Source Monitor Agent), Workflow 2 (Relevance and Summary Agent), Workflow 3 (Alert and Digest Agent). All three workflows share a single credential store. Inter-workflow data passing uses Airtable tbl_register as the shared state store; no direct workflow-to-workflow calls are made. This ensures each agent is independently restartable and auditable.
Agent 1 trigger mechanism
Scheduled poll. Workflow 1 fires on a daily cron schedule (default: 07:00 local time, configurable via SCAN_SCHEDULE_CRON). It calls the Feedly Streams API, checks each returned item against tbl_dedup, and passes new items to Workflow 2 by writing a new record to tbl_register with status=pending_classification.
Agent 2 trigger mechanism
Airtable webhook (record created event on tbl_register where status=pending_classification). The orchestration layer exposes a webhook receiver endpoint. Signature validation: every inbound request from Airtable must include the X-Airtable-Client-Secret header; the value is compared against AIRTABLE_WEBHOOK_SECRET before any processing begins. Requests failing validation return HTTP 401 and are logged.
Agent 3 trigger mechanism (alert)
Airtable webhook (record updated event on tbl_register where status changes to classified and relevance_score >= RELEVANCE_THRESHOLD). Signature validation applies as above. Agent 3 fires immediately for each qualifying record to post a Slack alert.
Agent 3 trigger mechanism (digest)
Scheduled poll. A second trigger in Workflow 3 fires every Monday at 08:00 (configurable via DIGEST_SCHEDULE_CRON). It queries tbl_register for all records created in the previous 7 days with status=classified and assembles the digest email.
Agent 3 trigger mechanism (overdue)
Scheduled poll. A third trigger in Workflow 3 fires daily at 09:00 and queries tbl_register for records where status=classified, acknowledged=false, and created_date < (today minus SLACK_OVERDUE_REMINDER_DAYS). A Slack reminder is posted for each match.
Credential store
All secrets, tokens, and configuration variables are stored in the automation platform's native encrypted credential vault. No values are written inline in workflow node configuration. See code block below for full contents.
Full credential store variable manifest. All entries must be present before any workflow is activated.
// Credential store contents
// Format: VARIABLE_NAME : type : description

// Feedly
FEEDLY_CLIENT_ID          : secret  : OAuth 2.0 client ID from Feedly developer portal
FEEDLY_CLIENT_SECRET      : secret  : OAuth 2.0 client secret
FEEDLY_ACCESS_TOKEN       : secret  : Short-lived access token (auto-refreshed on 401)
FEEDLY_REFRESH_TOKEN      : secret  : Long-lived refresh token
FEEDLY_STREAM_ID          : config  : Target collection stream ID (e.g. enterprise/...) 
FEEDLY_BOARD_IDS          : config  : Comma-separated board IDs for secondary streams
LAST_RUN_TIMESTAMP        : state   : Unix ms timestamp of last successful Feedly poll

// Airtable
AIRTABLE_PAT              : secret  : Personal Access Token (service account)
AIRTABLE_BASE_ID          : config  : Base ID (appXXXXXXXXXXXXXX format)
AIRTABLE_REGISTER_TABLE_ID: config  : tbl_register table ID
AIRTABLE_ROUTING_TABLE_ID : config  : tbl_routing table ID
AIRTABLE_DEDUP_TABLE_ID   : config  : tbl_dedup table ID
AIRTABLE_WEBHOOK_SECRET   : secret  : Shared secret for inbound webhook validation

// Notion
NOTION_TOKEN              : secret  : Internal Integration Token (secret_...)
NOTION_CLASSIFICATION_DB_ID: config : Database ID for topic/jurisdiction ruleset
NOTION_SUMMARY_PARENT_PAGE_ID: config: Parent page ID for new summary child pages
NOTION_API_VERSION        : config  : 2022-06-28

// Slack
SLACK_BOT_TOKEN           : secret  : Bot OAuth token (xoxb-...)
SLACK_SIGNING_SECRET      : secret  : Used for future event API signature validation
SLACK_DEFAULT_CHANNEL     : config  : Fallback channel ID (C012AB3CD format)
SLACK_OVERDUE_REMINDER_DAYS: config : Days before overdue reminder fires (default: 5)

// Gmail
GMAIL_CLIENT_ID           : secret  : Google OAuth 2.0 client ID
GMAIL_CLIENT_SECRET       : secret  : Google OAuth 2.0 client secret
GMAIL_REFRESH_TOKEN       : secret  : Offline refresh token
GMAIL_SENDER_ADDRESS      : config  : Sending email address
GMAIL_DIGEST_RECIPIENTS   : config  : Comma-separated To addresses for weekly digest
GMAIL_DIGEST_TEMPLATE_ID  : config  : Key for HTML template in orchestration template store

// Classification and routing
RELEVANCE_THRESHOLD       : config  : Minimum relevance score to pass classification (0-100)
SCAN_SCHEDULE_CRON        : config  : Cron expression for Agent 1 daily poll
DIGEST_SCHEDULE_CRON      : config  : Cron expression for Monday digest send
OVERDUE_CHECK_CRON        : config  : Cron expression for daily overdue check
State variables (LAST_RUN_TIMESTAMP) must be written back to the credential/config store at the end of each successful Agent 1 run. If a run fails before this write, the next run will re-fetch and re-process the same items. The deduplication check against tbl_dedup is the safety net for this scenario and must always run before any record is written to tbl_register.

05Error handling and retry logic

Every integration point has a defined failure behaviour. Unhandled exceptions must never fail silently. Any error not covered by the explicit cases below must be caught by a global error handler that logs the full error payload to a designated error log table in Airtable (tbl_errors) and posts a summary alert to the SLACK_DEFAULT_CHANNEL.

Integration
Scenario
Required behaviour
Feedly API
401 Unauthorized (token expired)
Automatically attempt token refresh using FEEDLY_REFRESH_TOKEN. If refresh succeeds, retry original request once. If refresh fails, halt workflow, log to tbl_errors, alert SLACK_DEFAULT_CHANNEL. Do not retry further without manual intervention.
Feedly API
429 Too Many Requests
Halt current run. Wait 60 seconds (exponential backoff: 60s, 120s, 240s up to 3 retries). If all retries exhausted, log to tbl_errors and skip this run cycle. Next scheduled run proceeds normally.
Feedly API
5xx Server Error
Retry up to 3 times with exponential backoff (30s, 60s, 120s). If all retries fail, log to tbl_errors, skip this run, alert SLACK_DEFAULT_CHANNEL. Items not fetched in this cycle will be captured in the next scheduled poll due to newerThan timestamp logic.
Airtable API (record write)
422 Unprocessable Entity (field validation failure)
Do not retry. Log the failing record payload and full error response to tbl_errors. Post alert to SLACK_DEFAULT_CHANNEL with the item_id and field name causing the failure. A FullSpec team member must review and correct the field mapping before the record can be reprocessed.
Airtable API (dedup check)
Network timeout or 5xx
Retry up to 3 times with 10-second intervals. If all retries fail, halt the current item processing and log to tbl_errors. Do not write the item to tbl_register without a confirmed dedup check result. Move to the next item in the batch.
Airtable Webhook (inbound to Agent 2 or 3)
Signature validation failure (X-Airtable-Client-Secret mismatch)
Return HTTP 401 immediately. Do not process the payload. Log the source IP and timestamp to tbl_errors. If more than 3 validation failures occur within 5 minutes, post a security alert to SLACK_DEFAULT_CHANNEL.
Notion API (summary page creation)
404 Not Found (parent page ID invalid or integration not shared)
Do not retry. Log to tbl_errors with the NOTION_SUMMARY_PARENT_PAGE_ID value. Alert SLACK_DEFAULT_CHANNEL. The Airtable tbl_register record should still be written with notion_page_url left blank rather than blocking the entire pipeline.
Notion API (classification DB read)
5xx or timeout
Retry up to 3 times with 15-second intervals. If all retries fail, halt Agent 2 for the current item and log to tbl_errors. Fall back to a cached copy of the classification ruleset if one exists from the previous successful read (max cache age: 24 hours). If no cache exists, halt and alert.
Slack API (chat.postMessage)
channel_not_found or not_in_channel
Do not retry. Post the alert to SLACK_DEFAULT_CHANNEL instead (fallback). Log the original target channel ID and item_id to tbl_errors so the routing table can be corrected. Update tbl_register with status=alert_fallback for audit visibility.
Slack API (chat.postMessage)
rate_limited (HTTP 429)
Read the Retry-After header value. Wait exactly that duration before retrying. Retry once only. If the second attempt also returns 429, queue the message and retry on the next Agent 3 invocation (up to 2 hours later). Log queued items.
Gmail API (messages.send)
401 or invalid_grant (OAuth token expired)
Attempt token refresh using GMAIL_REFRESH_TOKEN. If refresh succeeds, retry send once. If refresh fails, log to tbl_errors, alert SLACK_DEFAULT_CHANNEL, and queue the digest for manual resend. Do not silently drop the digest email.
Gmail API (messages.send)
Daily sending quota exceeded
Log to tbl_errors immediately. Do not retry on the same day. Alert SLACK_DEFAULT_CHANNEL with the digest recipient list so recipients can be notified manually. Reschedule the send attempt for the following day at the configured DIGEST_SCHEDULE_CRON time.
Any integration
Unhandled exception (any error type not matched above)
Catch all. Write full error payload (integration name, timestamp, workflow node, raw error message, item_id if available) to tbl_errors. Post a summary to SLACK_DEFAULT_CHANNEL immediately. Halt only the current item processing; allow the workflow to continue with remaining items in the batch. Unhandled exceptions must never fail silently.
The tbl_errors table in Airtable must be created as part of the base schema before any workflow is activated. Required fields: error_id (auto), integration, workflow_name, item_id, error_code, error_message, timestamp, resolved (checkbox). The FullSpec team reviews this table during the QA parallel-test period and at each scheduled health check post-launch. Contact support@gofullspec.com to report any error pattern not covered by the logic above.
Integration and API SpecPage 3 of 3

More documents for this process

Every document generated for Regulatory Change Monitoring.

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