Developer Guide: AUSLOCK API / SDK Overview (TTLock Ecosystem)
The AUSLOCK App uses the TTLock ecosystem for cloud access, gateways, and developer integrations. This page is a practical overview of the official resources and the most common patterns developers use when integrating locks into software platforms.
Open API docs:
TTLock Open API Documentation
Example endpoint (Unlock):
Unlock Endpoint (v3)
iOS SDK instructions:
iOS SDK
Android SDK instructions:
Android SDK
What you can build
- Property/booking automation: create timed codes and manage access by reservation windows
- Access management: staff codes, time schedules, role-based access
- Operations dashboards: door status, audit logs (varies by device + integration layer)
- Custom apps: mobile apps using iOS/Android SDK for on-site Bluetooth workflows
Core concepts (how the ecosystem fits together)
- Lock (device): the door hardware
- Gateway/Hub: connects the lock to the internet for remote actions and syncing (recommended for cloud automation)
- Cloud API: server-to-server integration for automation layers and platforms
- Mobile SDKs: app-side integration (Bluetooth + device workflows) for iOS/Android
Gateway note (important for “remote” features)
Many remote features (remote unlock, syncing scheduled codes off-site, some audit workflows) require a Wi-Fi gateway/hub. Without a gateway, device control may be limited to Bluetooth range and local phone proximity.
Typical integration patterns
Pattern A — PMS / booking platform → access codes
- Reservation created/updated
- Your system generates an access policy (code + start/end time)
- Push policy to lock via Open API
- Notify guest via SMS/email/message template
Pattern B — Access management dashboard
- Admin creates users/roles in your system
- Assign doors and schedules
- Sync to devices via API
- Audit events shown in a portal (capabilities vary by lock + gateway + configuration)
Pattern C — Mobile app (Bluetooth-first)
- Use iOS/Android SDK to pair/control on-site
- Ideal for installers or local access workflows
- Add gateway later if remote automation is required
Security & best practice
- Least privilege: use a dedicated integration account rather than a personal admin login.
- Token handling: store tokens securely server-side and rotate credentials if compromised.
- Timezone discipline: always align property timezone, system timezone, and lock timezone to avoid access windows drifting.
- Testing: validate against a test lock before rolling out portfolio-wide.
Troubleshooting (developer focused)
- Remote calls failing: confirm gateway online + lock bound; test remote unlock in-app first.
- Schedules wrong: fix timezone and device time; retest with a simple 1-hour window.
- Events/logs missing: logging detail depends on device + platform; confirm what the target lock supports.
Need help? If you’re building a custom integration, use our compatibility check and include: lock model + gateway model + your use case (codes, remote unlock, audit logs, or custom app).