Back to Asset & Equipment Tracking

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

Asset and Equipment Tracking

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

This document is the authoritative technical reference for every integration point in the Asset and Equipment Tracking automation. It covers tool authentication, exact OAuth scopes, webhook configuration, field-level mappings between systems, credential store layout, orchestration design, and defined failure behaviour for every integration. The FullSpec team uses this spec to build and configure all connections. No credentials, IDs, or environment-specific values are hardcoded in workflow logic; all are stored in the shared credential store as described in section 04.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agents
Airtable
Central asset register; trigger source and read/write target for all agents
OAuth 2.0 / Personal Access Token
Team plan ($20/month)
Agent 1 (Asset Intake), Agent 2 (Maintenance Scheduler), Agent 3 (Finance Sync)
QR Code Generator API
Generates printable QR code label URLs linked to asset records
API key (header)
Paid tier ($15/month)
Agent 1 (Asset Intake)
Slack
Assignment notifications, maintenance reminders, overdue loan alerts, monthly audit report
OAuth 2.0 (Bot token)
Free or Pro (existing workspace)
Agent 1 (Asset Intake), Agent 2 (Maintenance Scheduler)
Google Workspace
Calendar event creation for maintenance schedules; email fallback notifications
OAuth 2.0 (service account)
Business Starter or above (existing subscription)
Agent 2 (Maintenance Scheduler)
Xero
Fixed-asset creation and write-off records aligned to Airtable register
OAuth 2.0 (authorization code flow)
Standard plan or above
Agent 3 (Finance Sync)
Workflow automation platform
Orchestration layer; hosts all three agent workflows, credential store, and retry logic
N/A (internal platform auth)
Platform subscription ($49/month)
All agents
Before you connect anything: provision sandbox or test instances for every tool before entering production credentials. Airtable provides a duplicate-base option; Xero has a Demo Company; Slack test workspaces are free to create; Google Workspace supports additional test accounts under the same domain. All connections must be verified in sandbox before the production credential store is populated.

02Per-tool integration detail

Airtable

Airtable is the single source of truth for every asset record. The orchestration layer polls the base for new or updated records on a short interval and also receives webhook events when a record is created or a status field changes. All three agents read from and write back to this base.

Auth method
OAuth 2.0 Personal Access Token (PAT). Generate a PAT in Airtable account settings with token-level scopes. Store as AIRTABLE_PAT in the credential store. Do not use legacy API keys.
Required scopes
data.records:read | data.records:write | schema.bases:read | webhook:manage
Webhook / trigger setup
Create an Airtable webhook on the target base via POST /v0/bases/{baseId}/webhooks. Set cursor to watch for createdTime and modifiedTime on the Assets table. The orchestration layer must validate the X-Airtable-Client-Secret header on every inbound payload before processing.
Required configuration
Base ID stored as AIRTABLE_BASE_ID. Assets table ID stored as AIRTABLE_ASSETS_TABLE_ID. Field IDs for Asset_Status, Maintenance_Due_Date, Disposal_Flag, and Assigned_To must be resolved at setup and stored (not inlined as display names). Asset ID prefix and sequence seed confirmed with the operations team before go-live.
Rate limits
5 requests/second per base. At ~60 asset events/month (~2 events/day) plus scheduled polls, peak throughput is well below this limit. No throttling queue is required at current volume, but the orchestration layer must respect 429 responses with exponential backoff.
Constraints
Field names are case-sensitive in API calls. Use field IDs not display names in all payloads to prevent breakage if a column is renamed. Attachment fields (QR code URL) must be written as an array of URL objects, not a plain string.
// Trigger payload (webhook)
{ "baseId": "appXXXXXXXXXXXXXX", "tableId": "tblXXXXXXXXXXXXXX",
  "changedFieldIds": ["fldAssetStatus", "fldDisposalFlag"],
  "createdTime": "2024-05-01T09:14:00.000Z",
  "recordId": "recXXXXXXXXXXXXXX" }
// Write-back (QR URL patch)
PATCH /v0/{baseId}/{tableId}/{recordId}
{ "fields": { "fldQRCodeURL": [{ "url": "https://qr.example.com/asset-001.png" }] } }
QR Code Generator API

Called by Agent 1 (Asset Intake Agent) to generate a unique, scannable QR code for every confirmed asset record. The returned image URL is written back to the Airtable record and is also included in the Slack assignment message.

Auth method
API key passed in the request header as X-API-Key. Store as QR_API_KEY in the credential store.
Required scopes
No OAuth scopes. Single API key grants full access to QR generation endpoints on the paid tier.
Webhook / trigger setup
No inbound webhook. The orchestration layer makes an outbound POST request to the generation endpoint each time Agent 1 confirms a validated asset record.
Required configuration
Base endpoint stored as QR_API_BASE_URL. Default output format: PNG, size 400x400px, error-correction level M. The data payload encoded in each QR code must be the canonical asset detail URL: https://[YourCompany.com]/assets/{asset_id}. This URL pattern is stored as QR_ASSET_URL_TEMPLATE in the credential store.
Rate limits
Paid tier supports 500 requests/month minimum. At ~60 asset events/month the monthly cap is not approached. No throttling logic required at current volume.
Constraints
The generated URL is time-stable (permanent link) and must not be regenerated on subsequent record updates unless the asset ID changes. Regeneration overwrites the Airtable attachment, which would invalidate any already-printed labels.
// Outbound request
POST {QR_API_BASE_URL}/generate
Headers: { "X-API-Key": "{QR_API_KEY}" }
Body: { "data": "https://[YourCompany.com]/assets/AST-00042",
        "format": "PNG", "size": 400, "errorCorrection": "M" }
// Response
{ "success": true, "url": "https://qr.example.com/AST-00042.png",
  "expiresAt": null }
Slack

Used by Agent 1 for assignment notifications and by Agent 2 for maintenance reminders, overdue loan alerts, and the monthly audit summary post. All messages are sent via a dedicated bot installed in the [YourCompany.com] workspace.

Auth method
OAuth 2.0 Bot Token. Install the Slack app in the workspace, complete the OAuth flow, and store the resulting token as SLACK_BOT_TOKEN. The token must remain associated with a non-personal bot user to survive staff turnover.
Required scopes
chat:write | chat:write.public | users:read | users:read.email | channels:read | im:write
Webhook / trigger setup
No inbound Slack webhook is required for this build. All messages are outbound via the chat.postMessage API method. Channel IDs for the operations channel and the audit report channel must be resolved and stored at setup.
Required configuration
SLACK_OPS_CHANNEL_ID: the #operations channel for assignment and maintenance messages. SLACK_AUDIT_CHANNEL_ID: the #ops-audit channel for monthly report posts. SLACK_BOT_TOKEN stored in the credential store. User email-to-Slack-ID lookup is performed at runtime via users.lookupByEmail using the Assigned_To email from Airtable.
Rate limits
Tier 3 methods (chat.postMessage): 1 request/second. At ~60 events/month (~2/day) with no burst scenario, rate limiting is not a concern. The orchestration layer must still respect 429 Retry-After headers.
Constraints
Direct messages (im.open + chat.postMessage) require the im:write scope and the target user's Slack member ID. If a staff member is not found via email lookup, the message must fall back to posting in the #operations channel with an @mention of the ops manager.
// Assignment notification
POST https://slack.com/api/chat.postMessage
{ "channel": "{assignee_slack_id}",
  "text": "Asset AST-00042 (MacBook Pro 14\" M3) has been assigned to you.",
  "blocks": [ { "type": "section", "text": { "type": "mrkdwn",
    "text": "*Asset assigned:* AST-00042\n*Label URL:* <{qr_url}|Scan or print>" } } ] }
// Overdue alert (ops manager copy)
{ "channel": "{SLACK_OPS_CHANNEL_ID}",
  "text": ":warning: Asset AST-00031 is overdue for return. Borrower: @priya.nair. Due: 2024-04-28." }
Integration and API SpecPage 1 of 3
FS-DOC-05Technical
Google Workspace (Calendar and Gmail)

Used exclusively by Agent 2 (Maintenance Scheduler Agent) to create recurring Google Calendar events for maintenance intervals and to send email reminders where Slack delivery cannot be confirmed. Authentication uses a service account with domain-wide delegation so the agent can create events on behalf of the operations coordinator without requiring interactive login.

Auth method
OAuth 2.0 service account with domain-wide delegation. The service account JSON key is stored as GOOGLE_SERVICE_ACCOUNT_JSON in the credential store. The service account impersonates the operations coordinator email stored as GOOGLE_DELEGATE_EMAIL.
Required scopes
https://www.googleapis.com/auth/calendar | https://www.googleapis.com/auth/calendar.events | https://www.googleapis.com/auth/gmail.send
Webhook / trigger setup
No inbound Google webhook. Agent 2 is triggered by the Airtable webhook (maintenance date field update or new confirmed record). The agent then calls the Google Calendar API to create or update events. Google Calendar push notifications are not used in this build.
Required configuration
GOOGLE_DELEGATE_EMAIL: the operations coordinator's Google account used for calendar ownership. GOOGLE_CALENDAR_ID: the shared operations calendar ID (not 'primary'; use the explicit calendar ID from Calendar settings). Reminder lead times: 7-day and 1-day advance reminders configured as event-level popup and email reminders. All IDs stored in the credential store.
Rate limits
Google Calendar API: 10,000 requests/day per project (free quota). At ~60 asset events/month the build generates at most ~180 calendar API calls/month. Well within free quota. No throttling required.
Constraints
Recurring events use RRULE strings derived from the Maintenance_Interval field in Airtable (e.g. FREQ=MONTHLY;INTERVAL=3 for quarterly). If the maintenance interval is non-standard (e.g. 'as needed'), the agent must create a single event rather than a recurring series and flag the record in Airtable with a note.
// Calendar event creation
POST https://www.googleapis.com/calendar/v3/calendars/{GOOGLE_CALENDAR_ID}/events
{ "summary": "Maintenance Due: AST-00042 MacBook Pro 14\" M3",
  "start": { "date": "2024-08-01" },
  "end": { "date": "2024-08-01" },
  "recurrence": ["RRULE:FREQ=MONTHLY;INTERVAL=6"],
  "reminders": { "useDefault": false,
    "overrides": [ {"method": "email", "minutes": 10080},
                    {"method": "popup", "minutes": 1440} ] } }
Xero

Used exclusively by Agent 3 (Finance Sync Agent) to create fixed-asset records when a new asset is confirmed in Airtable, and to post write-off entries when a disposal flag is set. Xero's fixed-asset API requires the asset to be linked to the correct account code and depreciation method, both of which must be confirmed with the finance team before the agent is activated.

Auth method
OAuth 2.0 authorization code flow with PKCE. Scopes granted at connection time. Access token is short-lived (30 minutes); the orchestration layer must store and auto-refresh using the refresh token. Store XERO_CLIENT_ID, XERO_CLIENT_SECRET, XERO_REFRESH_TOKEN, and XERO_TENANT_ID in the credential store. Never store the access token at rest.
Required scopes
accounting.transactions | accounting.settings.read | assets | assets.read | offline_access
Webhook / trigger setup
No inbound Xero webhook. Agent 3 is triggered by the Airtable webhook when Asset_Status is set to 'Confirmed' or Disposal_Flag is set to true. The agent then makes outbound calls to the Xero Fixed Assets API.
Required configuration
XERO_TENANT_ID: the organisation GUID from the Xero connections endpoint. XERO_ASSET_ACCOUNT_CODE: the GL account code for fixed assets (e.g. '1100'), confirmed with the finance team and stored in the credential store. XERO_DEPRECIATION_METHOD: default method (e.g. 'StraightLine' or 'DiminishingValue'), stored as XERO_DEPRECIATION_METHOD. XERO_DEPRECIATION_RATE: annualised rate as a decimal (e.g. 0.25 for 25%), stored as XERO_DEPRECIATION_RATE. Per-category overrides are stored as a JSON map XERO_CATEGORY_DEPRECIATION_MAP.
Rate limits
Xero standard API: 60 calls/minute, 5,000 calls/day. At ~60 asset events/month the build makes at most ~120 Xero API calls/month (1 create + 1 confirm per asset). No throttling required. The orchestration layer must handle 429 responses with a 60-second backoff before retry.
Constraints
Xero fixed-asset records cannot be deleted via API once registered; disposal is handled by posting a write-off transaction via the accounting.transactions endpoint. Asset names in Xero are limited to 50 characters; the orchestration layer must truncate asset descriptions exceeding this limit before posting. Token refresh must be handled proactively (refresh before expiry, not after a 401 response) to avoid failed finance sync events going undetected.
// Create fixed-asset record
POST https://api.xero.com/assets.xro/1.0/Assets
Headers: { "Authorization": "Bearer {access_token}",
           "Xero-tenant-id": "{XERO_TENANT_ID}" }
{ "assetName": "MacBook Pro 14in M3 AST-00042",
  "assetNumber": "AST-00042",
  "purchaseDate": "2024-05-01",
  "purchasePrice": 2499.00,
  "assetStatus": "Draft",
  "bookDepreciationSetting": {
    "depreciationMethod": "StraightLine",
    "averagingMethod": "FullMonth",
    "depreciationRate": 0.25,
    "bookEffectiveDateOfChangeId": "01" } }

03Field mappings between tools

The tables below define the exact field-to-field mappings for each agent handoff. Use field IDs (not display names) in all API calls. Display names are included here for readability only.

Agent 1 handoff: Airtable to QR Code Generator API

Source tool
Source field
Destination tool
Destination field
Airtable
`fldAssetID` (Asset_ID)
QR Code Generator API
`data` (encoded URL: QR_ASSET_URL_TEMPLATE + Asset_ID)
Airtable
`fldAssetName` (Asset_Name)
QR Code Generator API
Included in `data` URL path only; not a separate param
QR Code Generator API
`url` (response)
Airtable
`fldQRCodeURL` (QR_Code_URL) written back as attachment array

Agent 1 handoff: Airtable to Slack (assignment notification)

Source tool
Source field
Destination tool
Destination field
Airtable
`fldAssetID` (Asset_ID)
Slack
`text` / `blocks.text` (message body)
Airtable
`fldAssetName` (Asset_Name)
Slack
`blocks.text` (message body)
Airtable
`fldAssignedTo` (Assigned_To_Email)
Slack
`channel` (resolved via users.lookupByEmail)
Airtable
`fldQRCodeURL` (QR_Code_URL)
Slack
`blocks.text` hyperlink (label scan/print URL)
Airtable
`fldPurchaseDate` (Purchase_Date)
Slack
`blocks.text` (message body, formatted)
Airtable
`fldCategory` (Asset_Category)
Slack
`blocks.text` (message body)

Agent 2 handoff: Airtable to Google Workspace Calendar

Source tool
Source field
Destination tool
Destination field
Airtable
`fldAssetID` (Asset_ID)
Google Calendar
`summary` prefix
Airtable
`fldAssetName` (Asset_Name)
Google Calendar
`summary` (event title body)
Airtable
`fldMaintenanceDueDate` (Maintenance_Due_Date)
Google Calendar
`start.date` and `end.date`
Airtable
`fldMaintenanceInterval` (Maintenance_Interval)
Google Calendar
`recurrence` (RRULE string, derived by agent logic)
Airtable
`fldAssignedTo` (Assigned_To_Email)
Google Calendar
`attendees[].email`
Airtable
`fldAssetID` (Asset_ID)
Google Calendar
`extendedProperties.private.airtable_record_id` (for future update lookups)

Agent 2 handoff: Airtable to Slack (overdue loan alert)

Source tool
Source field
Destination tool
Destination field
Airtable
`fldAssetID` (Asset_ID)
Slack
`text` (message body)
Airtable
`fldAssignedTo` (Assigned_To_Email)
Slack
`channel` (borrower DM, resolved via email lookup)
Airtable
`fldLoanReturnDate` (Loan_Return_Date)
Slack
`text` (formatted due date in message)
Airtable
`fldAssetName` (Asset_Name)
Slack
`text` (message body)
Airtable
Ops manager email (static config)
Slack
`SLACK_OPS_CHANNEL_ID` (copied alert)

Agent 3 handoff: Airtable to Xero (fixed-asset creation)

Source tool
Source field
Destination tool
Destination field
Airtable
`fldAssetID` (Asset_ID)
Xero
`assetNumber`
Airtable
`fldAssetName` (Asset_Name)
Xero
`assetName` (truncated to 50 chars if needed)
Airtable
`fldPurchaseDate` (Purchase_Date)
Xero
`purchaseDate` (ISO 8601 date)
Airtable
`fldPurchaseCost` (Purchase_Cost)
Xero
`purchasePrice` (numeric, 2 decimal places)
Airtable
`fldCategory` (Asset_Category)
Xero
`depreciationMethod` and `depreciationRate` (looked up from XERO_CATEGORY_DEPRECIATION_MAP)
Airtable
`fldDisposalFlag` (Disposal_Flag = true)
Xero
Write-off transaction via `accounting.transactions` endpoint
Airtable
`fldDisposalDate` (Disposal_Date)
Xero
`date` on write-off transaction
Integration and API SpecPage 2 of 3
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
One workflow per agent (three workflows total). Each workflow is independently deployable and versioned. A shared credential store is mounted across all three workflows so credentials are defined once and referenced by key name. No credentials appear inline in workflow logic.
Agent 1 trigger mechanism
Webhook (event-driven). Airtable fires a webhook on record create or material field update. The orchestration layer validates the X-Airtable-Client-Secret header before executing any logic. Signature validation is non-optional; unauthenticated payloads are rejected with HTTP 401 and logged.
Agent 2 trigger mechanism
Dual: webhook (for new confirmed records where Maintenance_Due_Date is populated) and scheduled poll (daily at 07:00 UTC to check for assets whose Maintenance_Due_Date or Loan_Return_Date falls within the next 7 days or is past due). The daily poll uses a filtered Airtable list-records call.
Agent 3 trigger mechanism
Webhook (event-driven). The same Airtable webhook as Agent 1 routes to Agent 3 when Asset_Status changes to 'Confirmed' or Disposal_Flag is set to true. A conditional router in the orchestration layer separates the intake path (Agent 1) from the finance path (Agent 3) based on these field values.
Credential store type
Platform-native encrypted environment variable store. All keys are scoped to the workspace and are not exposed in workflow execution logs. Rotation of any credential requires updating the single store entry only; no workflow code changes are needed.
Deployment environments
Two environments: sandbox and production. Each environment has its own credential store namespace (SANDBOX_ prefix for test values). Workflows are promoted from sandbox to production after QA sign-off. Production credentials are never used in sandbox.

Credential store contents (all values stored as encrypted environment variables):

Credential store — all keys required before any agent is activated
# Airtable
AIRTABLE_PAT=pat_xxxxxxxxxxxxxxxxxxxx
AIRTABLE_BASE_ID=appXXXXXXXXXXXXXX
AIRTABLE_ASSETS_TABLE_ID=tblXXXXXXXXXXXXXX
AIRTABLE_WEBHOOK_SECRET=whsec_xxxxxxxxxxxxxxxxxxxx

# QR Code Generator
QR_API_KEY=qr_live_xxxxxxxxxxxxxxxxxxxx
QR_API_BASE_URL=https://api.qrcodegenerator.example.com/v2
QR_ASSET_URL_TEMPLATE=https://[YourCompany.com]/assets/

# Slack
SLACK_BOT_TOKEN=xoxb-xxxxxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx
SLACK_OPS_CHANNEL_ID=C0XXXXXXXXX
SLACK_AUDIT_CHANNEL_ID=C0XXXXXXXXY

# Google Workspace
GOOGLE_SERVICE_ACCOUNT_JSON={...full service account key JSON...}
GOOGLE_DELEGATE_EMAIL=ops.coordinator@[YourCompany.com]
GOOGLE_CALENDAR_ID=xxxxxxxxxxxxxxxxxxxxxxxxxx@group.calendar.google.com

# Xero
XERO_CLIENT_ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XERO_CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
XERO_REFRESH_TOKEN=<stored and auto-rotated on each token exchange>
XERO_TENANT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
XERO_ASSET_ACCOUNT_CODE=1100
XERO_DEPRECIATION_METHOD=StraightLine
XERO_DEPRECIATION_RATE=0.25
XERO_CATEGORY_DEPRECIATION_MAP={"IT Hardware":0.25,"Furniture":0.10,"Vehicles":0.20}

# Orchestration platform
PLATFORM_WEBHOOK_SIGNING_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ENV=production
The XERO_REFRESH_TOKEN entry is updated automatically by the orchestration layer each time a token exchange succeeds. If a manual credential rotation is required (e.g. after a security event), re-run the Xero OAuth flow, capture the new refresh token, update the credential store, and restart the Finance Sync Agent workflow. Do not let the refresh token sit unused for more than 60 days or Xero will invalidate it.

05Error handling and retry logic

Every integration point has a defined failure behaviour. Unhandled exceptions must never fail silently. If a workflow step cannot be completed after all retries, it must write a structured error entry to the Airtable Errors log table and post a fallback alert to SLACK_OPS_CHANNEL_ID. The table below covers all defined scenarios.

Integration
Scenario
Required behaviour
Airtable webhook
Inbound payload fails signature validation (X-Airtable-Client-Secret mismatch)
Reject immediately with HTTP 401. Log the raw payload and timestamp to the platform error log. Do not process. Alert SLACK_OPS_CHANNEL_ID if more than 3 validation failures occur within 10 minutes.
Airtable read/write
429 Too Many Requests returned by Airtable API
Pause and retry with exponential backoff: 2s, 4s, 8s, 16s (max 4 retries). If all retries fail, write error to Airtable Errors table and post to SLACK_OPS_CHANNEL_ID. Do not drop the record.
Airtable write-back
QR code URL patch fails (Airtable field type mismatch or field ID not found)
Log the exact API error response to the platform error log. Post to SLACK_OPS_CHANNEL_ID with the record ID and field name. Halt the Agent 1 workflow for that record only. Do not proceed to Slack assignment notification until the write-back is confirmed.
QR Code Generator API
API returns non-200 response or times out (>10 seconds)
Retry up to 3 times with 5-second fixed delay. If all retries fail, set QR_Code_Status field in Airtable to 'Failed', post manual fallback alert to SLACK_OPS_CHANNEL_ID with the asset ID so the coordinator can generate the code manually.
Slack message delivery
users.lookupByEmail returns no match for Assigned_To_Email
Fall back to posting the assignment notification in SLACK_OPS_CHANNEL_ID with the assignee email in plain text and a request for the ops manager to forward it. Log the unmatched email to the Airtable Errors table.
Slack message delivery
chat.postMessage returns 429 or connection error
Retry up to 3 times with Retry-After header value (or 30 seconds if header is absent). If all retries fail, send the notification via Gmail as fallback using the Google Workspace service account (gmail.send scope). Log the failure.
Google Calendar
Event creation fails due to invalid RRULE (non-standard maintenance interval)
Create a single non-recurring event instead of a recurring series. Add a note to the event description flagging that recurrence could not be set. Update Airtable field fldMaintenanceIntervalFlag to 'Manual Review Required'. Post to SLACK_OPS_CHANNEL_ID.
Google Calendar
Service account token expired or delegation permission revoked
The orchestration layer detects a 401 from the Calendar API and attempts a service account re-auth. If re-auth fails, halt Agent 2, post a critical alert to SLACK_OPS_CHANNEL_ID, and email GOOGLE_DELEGATE_EMAIL with instructions to re-grant delegation. Log the failure with timestamp.
Xero token exchange
Refresh token expired or invalid (Xero returns invalid_grant)
Halt the Finance Sync Agent workflow immediately. Post a critical alert to SLACK_OPS_CHANNEL_ID and SLACK_AUDIT_CHANNEL_ID. The FullSpec team must re-run the Xero OAuth flow manually. No Xero writes should be attempted until the token is refreshed. Queue the failed record in Airtable with status 'Xero Sync Pending'.
Xero fixed-asset creation
Asset name exceeds 50 characters; Xero returns validation error
Truncate the assetName value to 49 characters and append an ellipsis before retrying. Log the truncation against the Airtable record in a fldXeroNotes field. Retry once. If the retry fails for any other reason, fall back to manual fallback behaviour below.
Xero fixed-asset creation
Account code or depreciation method not found in Xero organisation
Abort the write. Set fldXeroSyncStatus in Airtable to 'Config Error'. Post to SLACK_OPS_CHANNEL_ID and SLACK_AUDIT_CHANNEL_ID with the asset ID and the invalid code/method. The finance team must correct the XERO_ASSET_ACCOUNT_CODE or XERO_CATEGORY_DEPRECIATION_MAP before the agent retries.
All integrations
Unhandled exception in any agent workflow (uncaught error, unexpected payload shape, or platform crash)
The orchestration layer must catch all unhandled exceptions at the workflow level. Write a structured JSON error record to the Airtable Errors table (fields: timestamp, agent_name, error_type, error_message, record_id). Post an immediate alert to SLACK_OPS_CHANNEL_ID. Never fail silently.
The Airtable Errors table must be created before go-live with the following fields: Error_ID (autonumber), Timestamp (date/time), Agent_Name (single line), Error_Type (single line), Error_Message (long text), Record_ID (single line), Resolved (checkbox). The FullSpec team will configure this table as part of the Foundation build stage. The operations manager should review this table weekly during the first month after launch.
Integration and API SpecPage 3 of 3

More documents for this process

Every document generated for Asset & Equipment Tracking.

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