Integration setup checklist
Setup steps for 21 planned integrations, with developer tasks, customer authorization, write-access tests and vendor approval requirements.
These guides cover 21 planned integrations. None becomes available in Tack simply by creating a vendor API key. The connector must be implemented and tested, and each customer must authorize access to their own account.
Choose an integration
Section titled “Choose an integration”| Integration | Setup route described | Customer involvement |
|---|---|---|
| Housecall Pro | API key | Admin creates a key with the needed access |
| ServiceTitan | Registered app and tenant credentials | Tenant admin enables app; developer provisions credentials |
| Procore | Proposed DMSA data-connection app | Company admin installs and selects projects |
| Autodesk Construction Cloud | APS app and custom integration | Hub admin approves integration and project access |
| Salesforce | External Client App and OAuth | Org admin configures app/user permissions; user authorizes |
| kvCORE / BoldTrail | User API token | Admin confirms current token controls and contact access |
| Google Calendar | OAuth | Each user authorizes an editable calendar |
| Google Drive | OAuth and file selection | Each user authorizes and selects accessible files |
| Mercury Network | Vendor-approved route required | Account owner and Mercury must confirm order-write access |
| a la mode TOTAL | Merchant SDK/extension route to confirm | Appraiser/admin installs approved component |
| ACI | Vendor-approved SDK/import/API route to confirm | Appraiser/admin confirms product and enables approved route |
| Anow | Custom API/partner access to confirm | Firm admin and Anow must confirm entitlement |
| NetSuite | Integration record, role and OAuth | Account admin configures record and role; user authorizes |
| Acumatica | Tenant-specific connected application | Admin registers application and verifies endpoint contract |
| Epicor Kinetic | Instance API key and user permissions | ERP admin configures services, scope and test company |
| Epicor Prophet 21 | Deployment-specific middleware/API | ERP admin/partner provides licensed API and versioned guide |
| MaintainX | Organization API key | Admin creates key and confirms organization scope |
| Mitti | Service-user or personal API token | Admin/user creates token and grants item/site access |
| UpKeep | Organization API token | Admin creates token with an appropriate role |
| Limble | Client ID/secret and regional API host | Super Administrator generates credentials |
| Fiix | Instance application/access/secret keys | Admin registers application and restricts associated account |
Each linked guide contains vendor sources and identifies details that still need confirmation. These are implementation and onboarding plans, not claims that a vendor has approved Tack.
1. Establish the supported route
Section titled “1. Establish the supported route”The developer maps every proposed action to a documented vendor operation. Record whether it reads, creates a draft, sends something, changes money or deletes data. If no supported write path is confirmed, stop at research and obtain vendor approval before building that action.
The customer identifies their product edition, account/tenant, region, administrator and test environment. ERP customers also provide the deployed version and relevant customizations. Verify API entitlement before purchasing an upgrade.
2. Divide the work
Section titled “2. Divide the work”| Work | Agent/developer can complete | Human or vendor required |
|---|---|---|
| Research | Map endpoints, scopes, data fields and limitations | Vendor confirms gated access and ambiguous entitlement |
| Connector | Implement auth, encrypted storage, action handlers, audit records and mocked tests | Account owner approves the integration’s scope |
| Vendor app | Prepare registration details, callback URLs and permission list | Authorized person accepts terms, submits registration and completes review |
| Customer access | Prepare precise onboarding steps and validate configuration | Admin signs in, grants consent, creates credentials and approves roles |
| Testing | Automate checks against an explicitly authorized test environment | Operator selects test records and verifies business meaning |
| Release | Prepare deployment and monitor technical results | Owner accepts write behavior and authorizes production use |
An agent does not need the customer’s password to prepare these steps. Keep passwords, API keys, client secrets and refresh tokens out of texts, source control, logs and screenshots. Enter them only through an approved credential flow or secret store.
3. Record each customer’s configuration
Section titled “3. Record each customer’s configuration”Maintain a setup record containing:
- Customer and vendor tenant/account identifiers, API region and test/production environment.
- Authentication type, credential reference, token owner, expiration and rotation owner. Store references here, not secret values.
- Granted vendor scopes/roles, approved sites/projects and who on the customer’s team can use the connection.
- Field mappings, required custom fields, timezone, currency and default assignee where relevant.
- Permitted operations, approval requirements, test record IDs and the person who accepted the results.
A shared OAuth app registration can serve many customers, but each customer still needs its own authorization. Some ERP and partner routes also require separate app registrations or credentials. Never substitute one customer’s credentials for another’s.
4. Prove write access
Section titled “4. Prove write access”Use the specific test in the vendor guide, then complete this checklist:
- Read a designated test record and confirm its account, owner and location.
- Perform one approved, reversible write in a sandbox or explicitly designated test record. Keep sending, charging, posting and final delivery outside the initial test.
- Read the result back and have an operator inspect it in the vendor UI. A successful HTTP response alone is insufficient.
- Test a disallowed action or record to verify the intended access boundary. Distinguish vendor-enforced permissions from restrictions enforced only by our application.
- Retry the same operation to prove it cannot silently create duplicates. Check audit attribution and any notifications or automations it triggers.
- Exercise token renewal where applicable, then revoke the test connection and confirm further access fails. Clean up test records with approval.
Writes require all three: a supported endpoint, vendor-granted permission, and permission within Tack. Logging in successfully proves only authentication. Even a fully authorized endpoint may reject invalid fields or a prohibited business-state transition.
5. Release and maintain
Section titled “5. Release and maintain”Before exposing a connector, the developer must implement the secure connection flow, tenant isolation, action-specific approvals, error handling, duplicate protection and disconnection behavior. Run mocked tests, then authorized vendor tests. Update the integration’s availability only after the release is approved.
The customer authorizes production separately and reviews the first real results. Monitor failures and credential expiry; changes to roles, API versions, custom fields or vendor policies may require configuration updates or renewed consent.
Disconnecting must stop queued work and remove local credentials. Revoke access at the vendor too, using that integration’s documented procedure. Existing records remain unless the customer separately approves deleting or reversing them.
Guidance reviewed October 23, 2026. Vendor-specific sources appear in each integration guide.