Inkbox iMessage Channel for Constal

@constal/imessage connects one tenant-owned Inkbox identity to an Agent through ordinary Channel, AuthProvider, Credential, and Service Resources. A dedicated iMessage line is required to start conversations proactively; the shared router permits replies after the human connects first.

Use the packaged inkbox-identity-api-key Credential Provider to import and verify an identity-scoped key and its attached dedicated iMessage line; admin keys and identities without a dedicated line are rejected. Bind its output as the Service's authorization Credential. The Service uses the generic HTTP Driver with IMESSAGE_SERVICE_CONFIG and IMESSAGE_SERVICE_EGRESS. Import the identity's one-time webhook signing key through the packaged inkbox-webhook-signing-key Credential Provider; it removes Inkbox's whsec_ display prefix before storing the HMAC material. Bind its output to the AuthProvider's signing-key slot. Set the same identity UUID in both manifests. Subscribe the identity to imessage.received and imessage.reaction_received at the deployed Channel URL. The AuthProvider declares Inkbox's raw-body signature; Constal verifies it before Channel code runs.

The Channel keys Sessions by the provider's conversation UUID. Its pinned replies use conversation:<uuid>. Explicit Channel messages may use number:+E164 for a new conversation, or conversation:<uuid> for an existing one. Both call the same message.send Service operation. Inkbox does not document an idempotency key for message sends, so the operation is non-idempotent and an ambiguous result surfaces as outcome unknown.

The package manifests are templates: set tenant namespace and identity ID, create the scoped Credentials and Service, then install the Channel through the ordinary deployment API. Agent deployments opt in with the channels.constal.ai/imessage=enabled label.