Payload Handshake Integration Guide
This playbook defines the shared payload pattern Avoca expects when exchanging short-lived submission tokens with your services. Every workflow uses the same handshake, response envelope, and metadata wrapper so Avoca can plug into new resources without custom engineering.1. Handshake Overview
1.1 Request a Payload Token
payloadId:
1.2 Submit the Resource Payload
1.3 Standard Success Envelope
2. Shared Error Envelope
All endpoints return a consistent error shape. Flag retryable errors explicitly so Avoca can apply automated retry logic.3. Customer & Identity Payloads
3.1 Lookup by Phone or Address
3.2 Create Customer
4. Job Booking Payloads
4.1 Call-Type Catalogue
Publish the active call types so Avoca can sync and validate options.4.2 Create Job Submission
5. Equipment & Parts Payloads
5.1 Equipment Submission
5.2 Parts Submission
5.3 Part Catalogue Snapshot
6. Availability Payloads
6.1 Timeframe Submission
6.2 Detailed Slot Lookup (Direct API)
7. Operational Expectations
- Timeouts & retries: Document expected response times, retry windows, and whether errors are retryable. Avoca defaults to a 10 s timeout and retries once after 500 ms.
- Propagation: Note how long new customers or jobs take to appear in lookup endpoints; Avoca currently waits 10 s before re-querying.
- Alerts: Provide escalation contacts (emails or webhooks) for repeated timeouts; Avoca sends one alert after the second failure.
- Security: Define TLS versions, credential rotation cadence, and any additional signing or encryption requirements beyond HTTPS.
- Versioning: Describe how you will introduce new fields or endpoints (additive JSON properties, versioned paths) so Avoca can adopt changes without breaking.