Tickiti Interventions – Technical Reference
This article and the rest of the API documentation in this section are written for a technical audience — integrators and developers connecting external systems to Tickiti. Familiarity with HTTP, REST, JSON and bearer-token authentication is assumed.
This section provides the precise technical contract required to integrate a remote system with Tickiti interventions. For the conceptual explanation see Tickiti intervention integrator’s guide; for the fast path see Interventions quick start.
1. Terminology
| Term | Meaning |
|---|---|
| Intervention | A named workflow definition in Tickiti that maps to a remote decision process. |
| InterventionPayload | A stored instance of an intervention attached to a ticket. |
| UID | A unique identifier provided by the remote system representing a specific intervention instance. |
| Data bag | Arbitrary structured data supplied by the remote system and edited by staff. |
| Epilog endpoint | The remote system endpoint that Tickiti calls when staff submit the intervention. |
| Templates | {intervention}.private, .public, .final templates used to render ticket responses. |
2. Remote → Tickiti API
Endpoint
Headers
- Token must include ability:
create-ticket - Idempotency-Key is required for safe retries.
Request Body Schema
Field Definitions
| Field | Type | Required | Description |
|---|---|---|---|
| originator_email_address | string | Yes | End user email address |
| intervention | string | Yes | Must match Tickiti intervention name |
| uid | string | Yes | Unique identifier in remote system |
| data.data | object | Yes | Structured key/value data |
Example
Success Response
3. Tickiti → Remote Epilog Call
When staff submit the ticket response, Tickiti dispatches InterventionTicketEpilogJob.
Endpoint
Configured per intervention:
Headers
Request Body Schema
Field Definitions
| Field | Description |
|---|---|
| ticket_id | Tickiti internal ticket id |
| response_id | ID of staff response that triggered this |
| uid | Remote system unique identifier |
| intervention | Intervention name |
| action | Usually "submit" |
| data | Updated intervention data bag |
Example
4. Remote Epilog Response
Minimum Required
Optional Finalization Payload
If you want Tickiti to:
- Mark the intervention accepted
- Append audit text
- Post a final ticket response
Return:
Final Object Fields
| Field | Required | Description |
|---|---|---|
| response_id | Yes | Must match triggering response |
| ticket_audit | Yes | Appended to response audit log |
| additional fields | No | Available in {intervention}.final template |
5. HTTP Requirements
| Requirement | Description |
|---|---|
| Response code | Must return HTTP 200 |
| Timeout | Controlled by remote_timeout_seconds (default 10s) |
| Authentication | Bearer token required |
| Retries | Job retries on failure (exponential backoff) |
| Idempotency | Remote must handle duplicate calls safely |
6. Intervention Configuration (Tickiti)
Each intervention defines:
Core Fields
| Field | Purpose |
|---|---|
| name | Unique immutable identifier |
| title | Display name |
| queue_name | Target queue |
| notify_inbox_managers | Notification flag |
| fma_inbox_managers | Escalation flag |
Remote Settings
| Field | Purpose |
|---|---|
| remote_name | Used for token name |
| remote_epilog_url | Remote callback endpoint |
| remote_bearer_token | Stored encrypted |
| remote_timeout_seconds | HTTP timeout |
| remote_enabled | Enable/disable integration |
UI Field Types
| Type | Behavior |
|---|---|
| text | Text input |
| checkbox | Boolean toggle |
| label | Static informational text |
| hr | Horizontal divider |
Label Token Resolution
Labels may include tokens:
Tokens resolve from:
7. Template Requirements
Tickiti looks for templates:
Only .private is required.
8. Error Handling Contract
If the remote:
- Returns non-200 → Tickiti retries.
- Times out → Tickiti retries.
- Throws 4xx/5xx → Job retries until max attempts reached.
Remote systems must:
- Handle duplicate epilog calls safely.
- Use
uidas authoritative reference.
9. Security Model
| Direction | Auth model |
|---|---|
| Remote → Tickiti | Sanctum API token |
| Tickiti → Remote | Configured Bearer token |
| Token storage | Encrypted in DB |
| Tokens never displayed | After creation |
10. Data Storage Model (Tickiti)
Each intervention instance creates:
11. Operational Constraints
uidmust be globally unique within remote domain.- Intervention
namecannot change after creation. - Remote URL must support JSON.
- Payload size should remain modest (< 32KB recommended).
12. Recommended Best Practices
✔ Use stable domain IDs for uid
✔ Always return { ok:true } on success
✔ Make epilog idempotent
✔ Include meaningful ticket_audit text
✔ Log failures in remote system