Requests and responses

Request conventions

• Use Content-Type: application/json for JSON bodies. Preserve documented field names and enum casing.
• Unknown request fields are rejected with 422. Ignore unknown response fields so clients tolerate additive changes.
• Use Kits-Idempotency-Key where required by the operation. Do not reuse a key after changing the body or logical operation.
• Kits-Request-Id is for tracing, not duplicate-send protection. Keep the response request identifier for diagnostics.
• v1a does not offer ETag/If-Match concurrency. Follow each operation’s expected_* inputs and conflict responses.

A read-only authentication check

This reads the authenticated enum registry. It checks network access and authentication, not push service readiness or device delivery.

curl --include \
  --header "Authorization: Bearer ${KITS_SERVER_KEY}" \
  "${KITS_API_ORIGIN}/v1/registry/enums"

Success and partial outcomes

Message acceptance, push service processing and device confirmation are separate stages. Inspect status, counts, ignored_fields and pagination. Do not arbitrarily convert an unknown outcome into success or failure.

Exact request and response shapes

The API reference is generated from public OpenAPI and endpoint contracts. It shows required inputs, optional fields, types, bounds, authentication alternatives and per-response JSON Schema. It does not invent success bodies absent from the contract.