FS-DOC-05Technical
Integration and API Spec
Demo and Discovery Scheduling
[YourCompany.com] · Sales Department · Prepared by FullSpec · [Today's Date]
This document is the authoritative technical reference for every integration point in the Demo and Discovery Scheduling automation. It covers tool inventory, per-tool OAuth scopes and webhook configuration, field-level data mappings between agents, the orchestration layout and credential store structure, and the required error handling and retry behaviour at each integration boundary. The FullSpec team uses this spec to build, configure, and validate all connections. No credentials or scope strings should deviate from what is defined here without a documented change request.
01Tool inventory
Tool
Role in automation
Auth method
Min plan required
Used by agents
HubSpot
CRM trigger source, lead data reads, deal stage updates, contact timeline writes
OAuth 2.0 (private app token)
Sales Hub Starter ($45/mo) or above
Agent 1, Agent 3
Calendly
Prospect self-booking, booking confirmation events via webhook
OAuth 2.0 + webhook subscription
Standard ($12/mo) or above
Agent 2
Gmail
Outbound booking link email, 48-hr nudge, pre-call brief, 60-min reminder
OAuth 2.0 (Google Workspace)
Google Workspace (any tier) or free Gmail
Agent 2, Agent 3
Google Calendar
Calendar invite creation and update for rep and prospect
OAuth 2.0 (Google Workspace, shared token with Gmail app)
Google Workspace (any tier) or free
Agent 2
Zoom
Meeting creation, unique join-link generation per booking
OAuth 2.0 (Server-to-Server or user-level)
Pro ($15/mo) or above for API access
Agent 2
Slack
Internal sales-channel notification on booking confirmed
Bot token (OAuth 2.0 Slack app)
Pro ($8/mo) or above for App Directory installs
Agent 3
Orchestration layer
Workflow host, credential store, polling scheduler, webhook receiver, retry engine
N/A (internal to platform)
N/A
All agents
Before you connect anything: stand up a sandbox or developer environment for every tool and verify all connections there before switching to production credentials. HubSpot, Calendly, and Zoom all provide sandbox or test environments. Gmail and Google Calendar can be tested against a dedicated test Google Workspace account. Never use live prospect data or real sales-channel Slack workspaces during integration testing.
02Per-tool integration detail
HubSpot
Source of truth for lead data and deal lifecycle. Used by Agent 1 (Lead Qualification) to read contact and company properties, and by Agent 3 (Pre-Call Comms) to write deal stage updates and log activity. HubSpot also provides the workflow trigger via its native webhook or contact-property change event.
Auth method
OAuth 2.0 private app token. Generate under Settings > Integrations > Private Apps. Store the access token in the credential store under the key hubspot_private_app_token. Token does not expire but must be rotated if revoked.
Required scopes
crm.objects.contacts.read, crm.objects.contacts.write, crm.objects.deals.read, crm.objects.deals.write, crm.objects.companies.read, crm.schemas.contacts.read, crm.schemas.deals.read, timeline.read, timeline.write, forms.read
Webhook / trigger setup
Subscribe to contact.propertyChange events on the lifecycle_stage and hs_lead_status properties via the HubSpot Webhooks API (POST /webhooks/v3/{appId}/subscriptions). Set the target URL to the orchestration layer inbound webhook endpoint. Validate each incoming payload using the X-HubSpot-Signature-v3 header (HMAC-SHA256 of the raw body using the app client secret). Reject any request where the signature does not match.
Required configuration
Deal pipeline: confirm the target pipeline ID (stored as hubspot_pipeline_id). Deal stages required: Qualification In Progress, Demo Booked. Stage IDs for both must be stored as hubspot_stage_qualification_id and hubspot_stage_demo_booked_id in the credential store. Contact properties read: firstname, lastname, email, company, jobtitle, hs_analytics_source, num_employees. Custom property demo_request_type must exist and be set to either discovery or full_demo.
Rate limits
Private app tokens: 100 requests/10 seconds per token, 150,000 requests/day. At 42 runs/month (~1.4 runs/day, ~6-8 API calls per run), daily usage is under 20 calls. Throttling is not required at current volume. Build in a 200ms delay between sequential HubSpot calls within a single workflow execution as a precaution.
Constraints
Private app tokens are scoped to one HubSpot portal. If multi-portal support is needed in future, a separate token per portal is required. The Webhooks API requires a verified public HTTPS endpoint; localhost URLs are not accepted in production.
Calendly
Handles prospect self-booking. Agent 2 (Scheduling and Confirmation) delivers the Calendly booking URL via Gmail, then listens for the invitee.created webhook event to confirm a slot is locked. The orchestration layer does not poll Calendly; all triggers are push-based via webhook.
Auth method
OAuth 2.0. Client credentials stored as calendly_client_id and calendly_client_secret. Access token stored as calendly_access_token; refresh token stored as calendly_refresh_token. Refresh tokens are long-lived; the orchestration layer must handle token refresh on 401 responses automatically.
Required scopes
default (Calendly v2 uses a single unified scope tied to the OAuth grant; no granular scope strings are selectable at authorisation time. Access is governed by the user's Calendly role and the event types visible to the authorised user.)
Webhook / trigger setup
Register a webhook subscription via POST https://api.calendly.com/webhook_subscriptions. Subscribe to events: invitee.created, invitee.canceled. Set scope to user and pass the authorised user URI. Target URL must be the orchestration layer inbound HTTPS endpoint. Calendly signs each payload with an HMAC-SHA256 signature in the Calendly-Webhook-Signature header using the webhook signing key (stored as calendly_webhook_signing_key). Verify this signature on every inbound request before processing.
Required configuration
Two event type URIs must be stored: calendly_event_type_discovery_uri (for the discovery call link) and calendly_event_type_demo_uri (for the full demo link). The Lead Qualification Agent selects between these two URIs at routing time. Both event types must have the rep's availability and buffer times configured directly in Calendly before go-live.
Rate limits
Calendly API: 1,000 requests/hour per OAuth token. The automation makes at most 2 API calls per run (get event type details, confirm invitee). At 42 runs/month the rate limit is not a constraint. No throttling required.
Constraints
Calendly does not support server-initiated booking creation; the prospect must self-book via the link. If a booking is cancelled (invitee.canceled event), the automation must trigger a re-send of the booking link and revert the HubSpot deal stage. Multi-rep routing requires one Calendly user seat per rep; a single shared link cannot route to different reps dynamically on the Standard plan.
Gmail
All outbound prospect-facing emails are sent via Gmail using the Gmail API. Agent 2 sends the booking link email and the 48-hour nudge. Agent 3 sends the pre-call brief (24 hours before) and the 60-minute reminder. Each send uses a pre-approved template with HubSpot-sourced personalisation tokens substituted at runtime.
Auth method
OAuth 2.0 with offline access. Client credentials stored as gmail_client_id and gmail_client_secret. Access token stored as gmail_access_token; refresh token stored as gmail_refresh_token. The orchestration layer must refresh the access token automatically before expiry (access tokens expire after 3,600 seconds).
Required scopes
https://www.googleapis.com/auth/gmail.send, https://www.googleapis.com/auth/gmail.readonly (readonly is required only if the automation monitors for bounce or reply signals in future; for initial build, gmail.send is sufficient)
Webhook / trigger setup
No inbound webhook required for the initial build. All Gmail actions are outbound sends triggered by upstream events (qualification output, Calendly booking confirmed, 48-hour timer, 24-hour timer, 60-minute timer). Timers are managed by the orchestration layer scheduler, not by Gmail.
Required configuration
Four email templates must be stored in the orchestration layer's template store (not hardcoded in the workflow): gmail_template_booking_link (subject and body with tokens {{firstname}}, {{booking_url}}, {{meeting_type}}), gmail_template_nudge_48hr (subject and body with token {{firstname}}), gmail_template_precall_brief (subject and body with tokens {{firstname}}, {{company}}, {{meeting_datetime}}, {{zoom_join_url}}, {{agenda_summary}}), gmail_template_reminder_60min (subject and body with tokens {{firstname}}, {{zoom_join_url}}). The From address must match the authorised Gmail account; reply-to can be set to the assigned rep's address stored as rep_email_address in the run context.
Rate limits
Gmail API: 250 quota units per user per second; sending via users.messages.send costs 100 quota units per call. At 42 runs/month with up to 4 emails per run (168 emails/month, ~5.6/day), usage is well within limits. No throttling required. Daily sending limit is 2,000 messages/day for Google Workspace accounts.
Constraints
Emails sent via the API appear to come from the authenticated account. If the sales rep's own Gmail account is used, the OAuth token must be authorised per rep. A shared sending address (e.g. demos@[YourCompany.com]) authorised once is simpler to maintain. All template HTML must be tested for rendering across Gmail, Outlook, and Apple Mail before launch.
Integration and API SpecPage 1 of 4
FS-DOC-05Technical
Google Calendar
Used exclusively by Agent 2 to create the calendar invite for the confirmed booking. The invite is sent to both the prospect and the assigned rep. The Zoom join URL is embedded in the invite location and description fields. The Google Calendar integration shares the same OAuth 2.0 credentials as Gmail (same Google Workspace app registration).
Auth method
OAuth 2.0 shared with Gmail. Same access token and refresh token (gmail_access_token, gmail_refresh_token). No separate credential entry required if both scopes are granted in the same OAuth consent flow.
Required scopes
https://www.googleapis.com/auth/calendar.events
Webhook / trigger setup
No inbound webhook. Calendar invite creation is a single POST to https://www.googleapis.com/calendar/v3/calendars/primary/events triggered by the Calendly invitee.created event processed by Agent 2. The event is created with sendUpdates set to all so Google sends the invite to both attendees automatically.
Required configuration
Calendar ID stored as google_calendar_id (use primary for the rep's primary calendar or a specific calendar ID for a shared team calendar). Attendees array must include the prospect email (from Calendly invitee data) and the rep email (from rep_email_address in run context). Location field: set to the Zoom join URL. Description field: use template google_cal_description_template with tokens {{firstname}}, {{zoom_join_url}}, {{agenda_summary}}.
Rate limits
Google Calendar API: 1,000,000 quota units/day per project; events.insert costs 1 unit. At 42 events/month the rate limit is not a concern. No throttling required.
Constraints
The Google Cloud project must have the Calendar API enabled separately from the Gmail API. Both must be enabled in the same project for shared credential management. Event updates (e.g. if a booking is rescheduled via Calendly) require a PATCH call using the stored Google Calendar event ID; this ID must be saved to the HubSpot deal record or the orchestration run context immediately after event creation.
Zoom
Used by Agent 2 to create a unique Zoom meeting for each confirmed booking. The generated join URL is passed downstream to Google Calendar invite creation, the pre-call brief, and the 60-minute reminder email. Server-to-Server OAuth is the preferred method; user-level OAuth is required only if meetings must appear under individual rep accounts.
Auth method
Server-to-Server OAuth (recommended for a single shared Zoom account). App credentials stored as zoom_account_id, zoom_client_id, zoom_client_secret. Access token is generated on demand via POST https://zoom.us/oauth/token?grant_type=account_credentials&account_id={zoom_account_id} and cached in the credential store as zoom_access_token with its expiry timestamp. For per-rep meetings, user-level OAuth tokens must be stored per rep as zoom_access_token_{rep_id}.
Required scopes
meeting:write:admin (Server-to-Server); or meeting:write for user-level OAuth
Webhook / trigger setup
No inbound Zoom webhook required for this build. Meeting creation is outbound only, triggered by Agent 2 after receiving the Calendly invitee.created event. If future monitoring of meeting join/leave events is needed, subscribe to meeting.participant_joined via the Zoom Event Subscriptions dashboard.
Required configuration
Default meeting settings template stored as zoom_meeting_defaults: type 2 (scheduled), waiting_room enabled (true), mute_upon_entry (true), auto_recording set to cloud or none per the team's policy. The meeting topic token must be: Demo with {{firstname}} from {{company}}. The host email address for Server-to-Server meetings must be stored as zoom_host_email. Meeting duration default stored as zoom_default_duration_minutes (recommend 60).
Rate limits
Zoom API: 100 requests/day per user for meeting creation on Pro plan; 3,000 requests/day on Business and above. At 42 meetings/month (~1.4/day), the Pro plan limit is not a constraint. If volume grows past 80 meetings/month, monitor usage. No throttling required at current volume.
Constraints
A Zoom Pro account or above is required for API access. Free Zoom accounts do not support OAuth app creation or the meeting:write scope. The join_url returned by the API is unique per meeting and must not be reused across bookings. If a Calendly booking is cancelled, the corresponding Zoom meeting must be deleted via DELETE /meetings/{meetingId} to avoid orphaned meetings in the rep's account.
Slack
Used by Agent 3 to post a single formatted notification to the sales channel when a booking is confirmed. The message includes the prospect name, company, meeting time, and assigned rep. The Slack integration uses a dedicated bot token created via a custom Slack app installed to the workspace.
Auth method
Bot token OAuth 2.0. Create a Slack app at api.slack.com/apps. Install to workspace and grant bot token scopes. Store the bot token as slack_bot_token. Bot tokens do not expire unless revoked.
Required scopes
chat:write, chat:write.public (if posting to channels the bot has not been explicitly invited to)
Webhook / trigger setup
No inbound webhook. Slack notification is outbound only via POST https://slack.com/api/chat.postMessage, triggered by Agent 3 immediately after the HubSpot deal stage update is confirmed. The channel ID (not channel name) must be stored as slack_sales_channel_id to avoid failures if the channel is renamed.
Required configuration
Slack channel ID stored as slack_sales_channel_id. Message template stored as slack_notification_template. Block Kit payload format recommended. Minimum fields in the message: prospect firstname and lastname, company name, meeting date and time (formatted in the workspace's local timezone), assigned rep name (from rep_display_name in run context), and the Calendly event URL for reference.
Rate limits
Slack Web API: Tier 3 methods (chat.postMessage) allow 50 requests/minute. At 42 notifications/month the rate limit is not a constraint. No throttling required.
Constraints
The bot must be added as a member of the target Slack channel before messages can be posted. If chat:write.public is not granted, the bot must be manually invited to the channel with /invite @botname. Do not hardcode the channel name; always use the channel ID stored in the credential store.
03Field mappings between tools
The tables below document every field handoff between tools at each agent boundary. Use exact property names as shown; any deviation will cause mapping failures in the orchestration layer. All field names are case-sensitive.
Agent 1 handoff: HubSpot to Agent 2 (Scheduling and Confirmation Agent)
Source tool
Source field
Destination tool
Destination field
HubSpot
contact.properties.firstname
Run context
prospect_firstname
HubSpot
contact.properties.lastname
Run context
prospect_lastname
HubSpot
contact.properties.email
Run context
prospect_email
HubSpot
contact.properties.company
Run context
prospect_company
HubSpot
contact.properties.jobtitle
Run context
prospect_jobtitle
HubSpot
contact.properties.num_employees
Run context
prospect_company_size
HubSpot
contact.properties.hs_analytics_source
Run context
prospect_lead_source
HubSpot
contact.properties.demo_request_type
Run context
meeting_type
HubSpot
deal.id
Run context
hubspot_deal_id
Agent 1 output
routing_decision.booking_url
Gmail (booking link email)
{{booking_url}} token
Agent 1 output
routing_decision.meeting_type
Gmail (booking link email)
{{meeting_type}} token
Agent 2 handoff: Calendly webhook to Agent 2 internal and then to Agent 3 (Pre-Call Comms Agent)
Source tool
Source field
Destination tool
Destination field
Calendly webhook
payload.event.start_time
Run context
meeting_start_datetime_utc
Calendly webhook
payload.event.end_time
Run context
meeting_end_datetime_utc
Calendly webhook
payload.event.location.join_url
Run context
zoom_join_url
Calendly webhook
payload.invitee.email
Google Calendar (attendees)
attendee_email
Calendly webhook
payload.invitee.name
Run context
prospect_display_name
Calendly webhook
payload.event_type.uri
Run context
calendly_event_type_uri
Calendly webhook
payload.event.uri
Run context
calendly_event_uri
Zoom API response
join_url
Run context
zoom_join_url
Zoom API response
id
Run context
zoom_meeting_id
Google Calendar response
id
HubSpot deal property
google_calendar_event_id
Run context
zoom_join_url
Gmail (pre-call brief)
{{zoom_join_url}} token
Run context
meeting_start_datetime_utc
Gmail (pre-call brief)
{{meeting_datetime}} token
Run context
zoom_join_url
Gmail (60-min reminder)
{{zoom_join_url}} token
Agent 3 handoff: Run context and HubSpot to Gmail and Slack
Source tool
Source field
Destination tool
Destination field
Run context
prospect_firstname
Gmail (pre-call brief)
{{firstname}} token
Run context
prospect_company
Gmail (pre-call brief)
{{company}} token
Run context
meeting_start_datetime_utc
Gmail (pre-call brief)
{{meeting_datetime}} token
Run context
prospect_firstname
Gmail (60-min reminder)
{{firstname}} token
Run context
zoom_join_url
Gmail (60-min reminder)
{{zoom_join_url}} token
Run context
prospect_display_name
Slack notification
prospect name field in Block Kit
Run context
prospect_company
Slack notification
company field in Block Kit
Run context
meeting_start_datetime_utc
Slack notification
meeting time field in Block Kit
Run context
rep_display_name
Slack notification
rep assigned field in Block Kit
HubSpot deal
deal.id
HubSpot PATCH call
deal_id path parameter
Run context
hubspot_stage_demo_booked_id
HubSpot deal update
dealstage property value
Run context
meeting_start_datetime_utc
HubSpot deal update
demo_meeting_date property
Integration and API SpecPage 2 of 4
FS-DOC-05Technical
04Build stack and orchestration
Orchestration layout
Three discrete workflows, one per agent: Workflow 1 (Lead Qualification Agent), Workflow 2 (Scheduling and Confirmation Agent), Workflow 3 (Pre-Call Comms Agent). All three share a single credential store. Workflows are triggered by distinct events and do not poll each other; inter-workflow data is passed via the shared run context or a lightweight internal data store keyed on hubspot_deal_id.
Workflow 1 trigger
Webhook (push). HubSpot fires a contact.propertyChange event when lifecycle_stage or hs_lead_status changes to a demo-interest value. The orchestration layer exposes a dedicated HTTPS webhook endpoint for this workflow. Signature validation via X-HubSpot-Signature-v3 (HMAC-SHA256) is enforced on every inbound request before the workflow proceeds.
Workflow 2 trigger
Webhook (push). Calendly fires an invitee.created event to the orchestration layer's inbound webhook endpoint. Signature validation via HMAC-SHA256 using the calendly_webhook_signing_key is enforced. A secondary timer-based trigger handles the 48-hour nudge: the orchestration layer schedules a delayed execution at booking-link-send-time plus 48 hours, checks whether a Calendly invitee.created event has been received for the deal, and only sends the nudge if no booking is confirmed.
Workflow 3 trigger
Event-driven (internal). Fired by Workflow 2 upon successful completion of Zoom meeting creation and Google Calendar invite creation. The trigger passes the hubspot_deal_id and the run context payload. Within Workflow 3, two time-delayed sub-triggers are scheduled: pre-call brief fires at meeting_start_datetime_utc minus 24 hours; reminder fires at meeting_start_datetime_utc minus 60 minutes. These are scheduled jobs managed by the orchestration layer's built-in scheduler.
Credential store
Centralised encrypted credential store within the orchestration platform. All secrets are referenced by key name in workflow steps; no credential value is hardcoded in any workflow node, template, or configuration file. See code block below for the full credential manifest.
Environment strategy
Two environment sets: sandbox and production. Each environment has its own credential store entries prefixed with sandbox_ and prod_ respectively during development. Before go-live, the orchestration layer is switched to the production credential set. Sandbox Calendly and HubSpot environments are used for all pre-launch testing.
Full credential store key manifest. All keys must be present and validated before any workflow is activated in production.
// Credential store manifest (all keys required before first workflow activation)
// HubSpot
hubspot_private_app_token : string (HubSpot private app access token)
hubspot_pipeline_id : string (Target deal pipeline ID)
hubspot_stage_qualification_id : string (Deal stage ID: Qualification In Progress)
hubspot_stage_demo_booked_id : string (Deal stage ID: Demo Booked)
hubspot_webhook_client_secret : string (Used for X-HubSpot-Signature-v3 validation)
// Calendly
calendly_client_id : string (OAuth 2.0 client ID)
calendly_client_secret : string (OAuth 2.0 client secret)
calendly_access_token : string (Current access token, auto-refreshed)
calendly_refresh_token : string (Refresh token, long-lived)
calendly_webhook_signing_key : string (HMAC-SHA256 signing key for webhook validation)
calendly_event_type_discovery_uri : string (Calendly event type URI for discovery calls)
calendly_event_type_demo_uri : string (Calendly event type URI for full demos)
calendly_user_uri : string (Authorised Calendly user URI for webhook scope)
// Gmail + Google Calendar (shared Google OAuth app)
gmail_client_id : string (Google OAuth 2.0 client ID)
gmail_client_secret : string (Google OAuth 2.0 client secret)
gmail_access_token : string (Current access token, expires 3600s)
gmail_refresh_token : string (Offline refresh token)
google_calendar_id : string (Target calendar ID, e.g. primary or shared)
// Zoom
zoom_account_id : string (Server-to-Server OAuth account ID)
zoom_client_id : string (Zoom app client ID)
zoom_client_secret : string (Zoom app client secret)
zoom_access_token : string (Cached access token with expiry timestamp)
zoom_host_email : string (Email of Zoom host account for meeting creation)
zoom_default_duration_minutes : integer (Default meeting duration, recommend 60)
// Slack
slack_bot_token : string (Bot OAuth token, xoxb-... prefix)
slack_sales_channel_id : string (Channel ID, not channel name)
// Runtime context (populated per execution, not stored as secrets)
// rep_email_address, rep_display_name, rep_id: injected at workflow start
// from HubSpot deal owner lookup or static config per team setup
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 error log with the hubspot_deal_id, workflow name, step name, HTTP status code (where applicable), and timestamp. Where a manual fallback is defined, an alert must be posted to the Slack error channel (slack_error_channel_id, a separate channel from the sales notification channel).
Integration
Scenario
Required behaviour
HubSpot webhook inbound
Signature validation fails (X-HubSpot-Signature-v3 mismatch)
Reject immediately with HTTP 401. Log the attempt with raw header value. Do not process the payload. Alert to Slack error channel.
HubSpot API (contact read)
HTTP 429 rate limit exceeded
Retry with exponential backoff: wait 1s, 2s, 4s, 8s (max 4 retries). If still failing after 4 retries, log error and post Slack alert to error channel. Mark workflow execution as failed; do not proceed.
HubSpot API (deal stage update)
HTTP 4xx (invalid deal ID or stage ID)
Do not retry. Log error with deal ID and response body. Post Slack alert to error channel including hubspot_deal_id. Flag for manual CRM update by the sales rep.
Calendly webhook inbound
Signature validation fails
Reject with HTTP 401. Log and alert. Do not process.
Calendly webhook inbound
invitee.canceled event received after booking confirmed
Trigger cancellation sub-workflow: delete the Zoom meeting (DELETE /meetings/{zoom_meeting_id}), cancel the Google Calendar event (PATCH with status=cancelled), revert HubSpot deal stage to Qualification In Progress, and send re-booking link email to prospect via Gmail. Post Slack alert to sales channel.
Gmail API (send email)
HTTP 429 or 500 from Gmail API
Retry up to 3 times with exponential backoff: 2s, 4s, 8s. If all retries fail, log error with template name and prospect email. Post Slack alert to error channel. Do not skip silently.
Gmail API (send email)
Invalid recipient address (HTTP 400, permanent bounce)
Do not retry. Log the invalid address. Update HubSpot contact with a note flagging the invalid email. Post Slack alert to error channel so a rep can intervene.
Zoom API (meeting creation)
HTTP 429 rate limit or HTTP 500
Retry up to 3 times with exponential backoff: 2s, 4s, 8s. If all retries fail, proceed with Google Calendar invite using a placeholder join link (TBC - Zoom link pending). Post immediate Slack alert to error channel so a rep can create the Zoom meeting manually and update the invite.
Google Calendar API (event creation)
HTTP 403 (insufficient scope) or 404 (calendar not found)
Do not retry. Log error with calendar ID and scope list. Post Slack alert to error channel. Confirm the google_calendar_id credential and OAuth scope. The booking flow should not be blocked; proceed with Gmail confirmation email only, flagging that the calendar invite could not be created.
Slack API (chat.postMessage)
HTTP 429 or channel_not_found error
Retry once after 5 seconds. If still failing, log the error and the unsent message payload. Do not block the rest of Agent 3's workflow. Sales notification failures are non-blocking but must never fail silently.
48-hour nudge timer
Orchestration scheduler fails to fire the delayed execution
The orchestration layer must persist the scheduled job to durable storage (not in-memory) so it survives platform restarts. If the job is found to be missing on recovery, re-queue it. If the nudge window has already passed, log and skip; do not send a belated nudge.
All workflows
Unhandled exception or uncaught error at any step
Catch-all error handler must be configured at the workflow level. On any unhandled exception: log the full error with hubspot_deal_id, step name, and stack trace; post a Slack alert to the error channel; mark the execution as failed. Never allow a workflow to exit silently without a logged outcome.
The Slack error channel (slack_error_channel_id) must be a separate channel from the sales notification channel (slack_sales_channel_id). Configure the error channel before any testing begins. The FullSpec team will verify that error alerts fire correctly as part of the QA phase. Contact support@gofullspec.com if any integration credential or scope behaves differently from this spec in your environment.
Integration and API SpecPage 3 of 4
FS-DOC-05Technical
This Integration and API Spec is the single source of truth for all connection configuration in the Demo and Discovery Scheduling automation. Any change to a scope, credential key name, webhook endpoint, field mapping, or retry threshold must be reflected here before the change is applied to the orchestration layer. The FullSpec team maintains this document throughout the build. For questions or clarifications, contact support@gofullspec.com.
Integration and API SpecPage 4 of 4