Every resource in the Arowana API has a unique identifier. This page explains each ID type: what format it takes, where you receive it, and which request fields to pass it into.
Shortened placeholders in example IDs. Some docs pages use values like msg_a1b2c3d4 or cr_a1b2c3 where the real suffix would be a full UUID (msg_550e8400e29b...). The prefixes themselves (msg_, c_, cr_, ag_, tpl_, evt_) are real and stable — only the suffix portion is abbreviated for readability. The table below shows canonical formats.
Send responses vs message log responses use different field names for the message identifier:
ContextField nameExample
POST /v1/messages responsemessage_idmsg_a1b2c3d4
GET /v1/messages list itemidmsg_a1b2c3d4
GET /v1/messages/{id} objectidmsg_a1b2c3d4
Webhook data payloadmessage_idmsg_a1b2c3d4
The value is the same — only the field name differs between send responses (message_id) and log objects (id).

​
Quick reference

ResourceField nameFormatExample
Contactcontact_idc_ prefixc_550e8400e29b41d4a716446655440000
Messagemessage_idmsg_ prefixmsg_550e8400e29b41d4a716446655440001
RCS agentagent_idag_draft_ or ag_live_ prefixag_draft_550e8400...
Consent recordrecord_idcr_ prefixcr_550e8400e29b41d4a716446655440002
Channelchannel_idch_ prefixch_550e8400e29b41d4a716446655440003
Campaigncampaign_idUUID550e8400-e29b-41d4-a716-446655440004
Templatetemplate_idtpl_ prefixtpl_550e8400e29b41d4a716446655440005
Webhook endpointwebhook_idUUID550e8400-e29b-41d4-a716-446655440006
Webhook eventidevt_ prefixevt_550e8400e29b41d4a716446655440007

​
Contact ID

Format: c_ prefix — c_550e8400e29b41d4a716446655440000 Contact IDs use a c_ prefix followed by a UUID. You receive a contact ID in the response to POST /v1/contacts or POST /v1/contacts/import. Used in:
  • GET /v1/contacts/{id} — fetch a contact
  • PATCH /v1/contacts/{id} — update a contact
  • DELETE /v1/contacts/{id} — delete a contact
  • GET /v1/contacts/{id}/consent — read consent records
  • POST /v1/contacts/{id}/consent — set consent
  • Message logs — the contact_id field on every message record
How to get it: Call POST /v1/contacts and read id from the response. If you use an external_id (e.g. your CRM user ID), you can look up the contact by external ID.

​
Message ID

Format: msg_ prefix — msg_a1b2c3d4 Every outbound send or inbound message receives a unique message ID. Used in:
  • GET /v1/messages/{id} — fetch full message detail and delivery timeline
  • DELETE /v1/messages/{id} — revoke a queued message
  • Webhook payloads — data.message_id on all message.* events
How to get it: Call POST /v1/messages and read message_id from the response. Also available in GET /v1/messages list results.

​
RCS Agent ID

Format: ag_draft_ or ag_live_ prefix — ag_draft_550e8400..., ag_live_550e8400... The prefix is chosen at agent creation based on whether you created the agent as a draft or directly in an approved/live state. It never changes after creation — an agent created as a draft keeps the ag_draft_ prefix even after it is approved and launched.
Do not use the ag_draft_ / ag_live_ prefix to determine whether an agent is currently live. An agent created as a draft that later gets approved and launched will always have an ag_draft_ prefix. Always check the status field from GET /v1/rcs/agents/{id} for the authoritative current state.
PrefixMeaning
ag_draft_Agent was created in draft state (may now be APPROVED and live — check status)
ag_live_Agent was created already in a live/approved state
Used in:
  • GET /v1/rcs/agents/{id} — get agent details
  • PATCH /v1/rcs/agents/{id} — update agent profile
  • POST /v1/rcs/agents/{id}/submit — submit for review
  • GET /v1/rcs/agents/{id}/launch — check carrier launch status
  • POST /v1/messages — the agent_id body field on every RCS send
  • Webhook payloads — data.agent_id on agent.* and conversation.* events
How to get it: Call POST /v1/rcs/agents and read agent_id from the response. Also visible in the RCS dashboard.
Format: cr_ prefix — cr_a1b2c3 Each consent record is scoped to one contact + channel type + message type combination. Used in:
  • DELETE /v1/contacts/{id}/consent/{record_id} — revoke a specific consent record
How to get it: Call GET /v1/contacts/{id}/consent or POST /v1/contacts/{id}/consent and read id from the consent record. Also returned inline in GET /v1/contacts/{id} inside consent_records[].

​
Channel ID

Format: ch_ prefix — ch_550e8400e29b41d4a716446655440003 Channels are configured in the dashboard. Each channel represents a verified sender identity for one transport (Email, RCS, or SMS). RCS: agent_id on sends, channel_id in logs RCS has two related but distinct concepts:
FieldWhere usedWhat it identifies
agent_idPOST /v1/messages request bodyThe Google-registered brand agent (used for sending)
channel_idGET /v1/messages and GET /v1/messages/{id} responseThe platform channel record in the message log
When you send an RCS message you pass agent_id. The platform internally maps the agent to a workspace channel and records the send against that channel. Message history endpoints expose channel_id (not agent_id) in their response objects because the log schema is uniform across all channel types (Email, RCS, SMS). Both IDs are visible in the dashboard — they are different references to the same configured channel. Used in:
  • POST /v1/messages — channel_id on Email and SMS sends; agent_id on RCS sends
  • Message logs — the channel_id field on every message record (including RCS)
  • SMS webhook payloads — data.channel_id
How to get it: Open the Channels section in your dashboard and copy the channel ID. Channel IDs do not change.

​
Campaign ID

Format: UUID — 550e8400-e29b-41d4-a716-446655440002 Campaigns are created and managed in the dashboard UI. Used in:
  • POST /v1/campaigns/{id}/trigger — start a campaign
  • POST /v1/campaigns/{id}/pause — pause a running campaign
  • POST /v1/campaigns/{id}/resume — resume a paused campaign
  • GET /v1/campaigns/{id}/status — poll campaign status
  • Message logs — the campaign_id field links sends to the originating campaign
  • GET /v1/messages?campaign_id=... — filter message history by campaign
How to get it: Open the campaign in your dashboard and copy the ID from the URL or campaign detail panel.

​
Template ID

Format: tpl_ prefix — tpl_xxxx Templates are created in the dashboard template editor. Used in:
  • POST /v1/messages — the template_id body field on template-based sends (email and RCS)
How to get it: Open the template in your dashboard and copy the template ID.

​
Webhook Endpoint ID

Format: UUID — 550e8400-e29b-41d4-a716-446655440003 Webhook endpoint IDs are assigned when you register an endpoint. Used in:
  • PATCH /v1/webhooks/{id} — update URL, events, or rotate secret
  • DELETE /v1/webhooks/{id} — remove endpoint
  • POST /v1/webhooks/{id}/test — send a test payload
How to get it: Call POST /v1/webhooks and read id from the response, or call GET /v1/webhooks to list all registered endpoints.

​
Event ID (webhook payloads)

Format: evt_ prefix — evt_a1b2c3 Every event delivered to your webhook endpoint has a unique event ID. Used for: Deduplication. Store processed event IDs to detect and safely ignore retried deliveries. 
const processedEvents = new Set();

app.post("/webhooks/arowana", (req, res) => {
  const { id, event, data } = req.body;
  if (processedEvents.has(id)) {
    return res.status(200).send("already processed");
  }
  processedEvents.add(id);
  // handle event...
  res.status(200).send("OK");
});
How to get it: Always present in the webhook payload as the top-level id field.