The Arming Experience

Defining how arming works is not just a technical step—it's an operational agreement. This section outlines the boundaries of authority between CHeKT and your platform.

Understanding Arming Authority

The Arming Experience determines who has control over the armed/disarmed state of a security system. This is not a technical preference—it's a fundamental architectural decision that defines:

• Who owns the arming state
• Where users go to arm/disarm
• How state synchronization works
• What happens during failures

Two Arming Models

Comparison Table

Model Details

Partner-Triggered Arming

When to Choose:

• You have physical security panels users interact with
• Your platform has an existing arming interface
• You want full control over arming logic and user experience
• Your users expect to arm/disarm through your app

Technical Flow:

User → Partner Panel/App → Partner Platform → CHeKT API

API Requirements:

POST /v1/sites/{site_id}/arming-state
Content-Type: application/json
Authorization: Bearer PARTNER_M2M_TOKEN

{
  "state": "armed_away",
  "partition": "all",
  "timestamp": "2024-01-15T10:30:00Z",
  "user_id": "user_123",
  "source": "keypad"
}

Responsibilities:

• ✅ Implement real-time state sync within 5 seconds
• ✅ Handle all user-initiated arming/disarming
• ✅ Manage entry/exit delays
• ✅ Send accurate timestamps
• ✅ Handle sync failures and retries

CHeKT-Triggered Arming

When to Choose:

• You're building a cloud-first integration without physical panels
• You want CHeKT to handle the entire arming experience
• Your users will use CHeKT's mobile app for arming
• You want automated scheduling managed by CHeKT

Technical Flow:

User → CHeKT Mobile App → CHeKT Cloud → Partner Webhook

Webhook Events:

{
  "event_type": "arming.state_changed",
  "site_id": "site_123",
  "new_state": "armed_away",
  "previous_state": "disarmed",
  "timestamp": "2024-01-15T10:30:00Z",
  "triggered_by": "user_123",
  "source": "mobile_app"
}

Responsibilities:

• ✅ Implement webhook endpoints for arming events
• ✅ Update your system state based on CHeKT events
• ✅ Handle webhook retries and failures
• ✅ Verify webhook signatures
• ✅ Respond to arming commands from CHeKT

Decision Matrix

Use this matrix to determine which model fits your integration:

Operational Contract

By implementing either model, you agree to:

1. Consistency

• Once chosen, the arming model cannot be changed without re-certification
• All sites under your partnership must use the same model
• Mixing models is strictly prohibited

2. Reliability

• Arming state must be accurate at all times
• State changes must be reflected within 5 seconds
• Failed syncs must trigger operational alerts
• 99.9% uptime SLA for arming APIs

3. Security

• User attribution must be preserved for all arming events
• Audit trails must be maintained
• Invalid state transitions must be rejected
• Security events cannot be lost or delayed

4. User Experience

• Entry/exit delays must match panel configuration
• Arming failures must provide actionable feedback
• Users must have a clear, reliable way to arm/disarm
• Unexpected state changes must be explained

Implementation Checklist

For Partner-Triggered Arming

• Implement /v1/sites/{id}/arming-state API endpoint
• Handle all arming state changes from your platform
• Send state updates within 5 seconds of user action
• Implement exponential backoff for failed syncs
• Test partition-specific arming scenarios
• Verify timestamp accuracy (must be UTC)
• Handle entry/exit delays correctly
• Test open zone failures
• Implement retry logic for network failures
• Add operational monitoring and alerting

For CHeKT-Triggered Arming

• Configure webhook endpoints to receive arming events
• Implement webhook signature verification
• Handle arming.state_changed event types
• Update your system state based on CHeKT events
• Test scheduled arming/disarming scenarios
• Verify event delivery and retry logic
• Handle webhook delivery failures gracefully
• Implement idempotency for duplicate events
• Test arming via CHeKT mobile app
• Add webhook monitoring and alerting

Common Scenarios

Scenario 1: Arm Failure (Open Zone)

1. User attempts to arm system
2. Partner detects Zone 5 (Back Door) is open
3. Partner sends ARM_FAILURE event to CHeKT
4. CHeKT notifies user: "Cannot arm - Back Door is open"
5. System remains disarmed

Scenario 2: Successful Arm Away

1. User initiates Arm Away
2. Exit delay starts (60 seconds)
3. Partner sends ARMING_IN_PROGRESS to CHeKT
4. User exits building
5. Exit delay completes
6. Partner sends ARMED_AWAY to CHeKT
7. CHeKT confirms and updates monitoring status

Scenario 3: Disarm During Entry Delay

1. System is ARMED_AWAY
2. Front door opens → Entry delay starts (30 seconds)
3. Partner sends ENTRY_DELAY to CHeKT
4. User enters code at panel
5. Partner sends DISARMED to CHeKT
6. CHeKT cancels alarm countdown

Testing Requirements

Before production deployment, you must test:

• All arming mode transitions (Away, Stay, Night, Disarmed)
• Entry and exit delay scenarios
• Open zone arm failures
• User code validation
• Network failure recovery
• State synchronization edge cases
• Webhook retry logic (for CHeKT-Triggered)
• API retry logic (for Partner-Triggered)
• Timestamp accuracy across time zones
• Concurrent arming/disarming requests

Certification Process

1. Model Selection: Choose your arming model
2. Implementation: Build according to specifications
3. Testing: Complete all test scenarios
4. Review: Schedule technical review with CHeKT
5. Certification: Pass certification requirements
6. Production: Deploy to production

Support and Next Steps

Next Steps:

1. Review the Partner Event APIs for technical specifications
2. Implement the chosen model following the checklist above
3. Complete the testing requirements
4. Schedule integration testing with CHeKT's certification team
5. Pass certification before production deployment