UpKeep
Planned: close work orders, log downtime and create requests in UpKeep by text. Needs the UpKeep Enterprise plan.
Todavía no está disponible. Esta página describe lo que tenemos planeado para UpKeep. Pregunta en tu chat y te avisamos por mensaje cuando esté listo.
Esta página todavía no está traducida. Te mostramos la versión en inglés.
Status: planned — not available to connect in Tack yet. These steps prepare the integration; creating vendor credentials does not enable it in the app.
Planned workflows
Section titled “Planned workflows”Planned for UpKeep:
| You text | What would happen in UpKeep |
|---|---|
| “Replaced the belt on Mixer 2, 25 min” | Closes the work order with labor |
| “Mixer 2 down since 6am” | Logs downtime |
These are intended workflows, not a guarantee that every operation is exposed by the vendor. Each must pass the API and permission checks below before release.
Before you start
Section titled “Before you start”UpKeep’s current API reference specifies an Enterprise plan. Use its organization API-token flow for a new integration; older tutorials may describe the legacy username/password session flow. UpKeep API reference.
Developer setup — once
Section titled “Developer setup — once”- Implement Bearer authentication for organization API tokens and encrypted, customer-specific secret storage.
- Review supported work-order and asset endpoints and map required fields/status IDs.
- Check token limitations: organization tokens cannot modify users or webhooks, or import people/teams. Do not design those operations around a broader work-order role.
Customer setup — repeat for each organization
Section titled “Customer setup — repeat for each organization”- An administrator opens Settings → API Tokens → Create token.
- Enter a recognizable integration name and select the role whose permissions the token should use.
- Create the token and copy it once into secure storage. Record the role, organization and token name; API activity is attributed to that name.
- Review the role’s actual work-order/asset permissions and locations with the administrator before enabling writes.
The current token and authentication instructions cover these settings and restrictions.
Verify write access
Section titled “Verify write access”Read a designated test asset and create a test work order at its location. Read it back and verify the token’s audit identity, assigned user and status. Check an intentionally disallowed write to confirm role restrictions work. Avoid changing real user accounts as a test.
Disconnect and troubleshoot
Section titled “Disconnect and troubleshoot”Revoke the dedicated token in Settings → API Tokens, discard the local secret and confirm requests fail. If authentication succeeds but an operation is denied, check the chosen role and whether organization tokens support that operation. An older Session-Token tutorial is not interchangeable with this Bearer-token setup.
Who completes the work?
Section titled “Who completes the work?”An agent/developer can implement the connector, field mappings and automated checks. A customer administrator must authorize account access and permissions; the vendor must approve any restricted partner access. A business operator verifies the test records before production use. Follow the shared setup and release checklist for credential handling, approval gates and launch checks.
Setup guidance reviewed October 23, 2026. Vendor menus and entitlements can change; unresolved details are called out above.