Channex-compatible API

Repull serves the Channex API as a drop-in replacement. Point an integration written against Channex at Repull's base URL, send a Repull API key, and it keeps working: the same paths, request and response bodies, filters, pagination, envelopes, error shapes, webhooks and HMAC signatures. Nothing has to be rewritten. Every operation in Channex's published API has a route; the coverage table shows which work fully, which work with a named limit, and which return a Channex-shaped error.

Quick start

1. Create an API key in the Repull dashboard.
2. Replace the base URL. https://app.channex.io/api/v1 becomes https://api.repull.dev/channex/api/v1.
3. Send the Repull key in the user-api-key header, where your Channex key was.

BASE=https://api.repull.dev/channex/api/v1

curl "$BASE/properties?pagination[page]=1&pagination[limit]=10" \
  -H "user-api-key: sk_live_YOUR_KEY"

Everything else is unchanged: filter[...], pagination[...] and order[...] query parameters, { data, meta } on success, { errors: { code, title, details } } on failure with the same HTTP status. A missing or unknown key returns Channex's 401; an unknown path returns 404 resource_not_found; a wrong method returns 405 with an Allow header. The base URL without /api (https://api.repull.dev/channex/v1) works too.

How Channex concepts map

curl -X POST "$BASE/restrictions" \
  -H "user-api-key: sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "values": [
        { "property_id": "PROPERTY_ID", "rate_plan_id": "RATE_PLAN_ID",
          "date_from": "2026-12-01", "date_to": "2026-12-14",
          "rate": "189.00", "min_stay_arrival": 3, "closed_to_arrival": false }
      ] }'

Channels API and the mapping iframe

The Channels API (/channels, /channels/:id/mappings, activate, deactivate, /channels/list, /channels/codes, test_connection, mapping_details) is available for Booking.com (BDC), Airbnb (ABB) and Vrbo (VRB). Every connection in your workspace appears as a channel, including ones made from the dashboard.

If your app embeds Channex's channel mapping screen, keep the button and change the server. Request a one-time token as before, then load https://api.repull.dev/channex/auth/exchange with the same query string. The token is single-use and lasts 15 minutes. It opens the hosted mapping screen for that workspace, limited to the channels in channels or available_channels. Only redirect_to=/channels exists; other pages are refused before the token is spent.

curl -X POST "$BASE/auth/one_time_token" \
  -H "user-api-key: sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "one_time_token": { "property_id": "PROPERTY_ID", "username": "jane@pms.example.com" } }'

# { "data": { "token": "..." }, "meta": { "message": "..." } }

Webhooks

Register webhooks with POST /webhooks exactly as on Channex: callback_url, event_mask, property_id or is_global, send_data, headers, request_params, is_signed and signing_key_id, with Channex's defaults. Deliveries use Channex's event names and envelope. A property webhook wins over a global one on the same URL, so the endpoint gets one delivery, not two. Delivery is retried, and GET /webhooks/:id/logs shows every attempt.

{
  "event": "booking",
  "payload": {
    "booking_id": "9c1a2b3c-...",
    "property_id": "4f6e7d8c-...",
    "revision_id": "e2d4f6a8-..."
  },
  "property_id": "4f6e7d8c-...",
  "user_id": null,
  "timestamp": "2026-10-22T14:03:11.204Z"
}

HMAC signing

Signing is byte-for-byte Channex's, so your existing verifier works unchanged. A signed delivery carries:

• x-hmac-timestamp: the Unix time used to sign.
• x-hmac-signature-256: lowercase hex HMAC-SHA256 of <timestamp>.<raw body>. During a rotation it holds two signatures, comma-separated, current first.
• x-hmac-keys-256: ... plus the last six characters of each secret, in the same order.

Your secrets carry over. The import recreates each signing key under its Channex id; install the secret your endpoints already verify with through POST /signing_keys/:id/rotate and { "signing_key": { "secret": "..." } }. POST /signing_keys and generate accept a secret too, of 32 to 256 characters; leave it out and Repull generates one, shown once. generate adds a pending secret and rotate promotes it. Where Channex asks for billing_account_id, use your workspace id; the response names it if you send your old one.

import crypto from 'node:crypto'

// rawBody must be the exact bytes received, before JSON parsing.
export function verifyChannexWebhook(rawBody: string, headers: Headers, secret: string): boolean {
  const ts = headers.get('x-hmac-timestamp')
  const sigs = (headers.get('x-hmac-signature-256') ?? '').split(',')
  if (!ts || Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false

  const expected = crypto.createHmac('sha256', secret).update(`${ts}.${rawBody}`).digest('hex')
  return sigs.some(s =>
    s.length === expected.length && crypto.timingSafeEqual(Buffer.from(s), Buffer.from(expected)),
  )
}

Events

Every event Channex lists is accepted in event_mask (GET /webhooks/events). These are accepted but not sent, and registering one returns a warning:

• published_review: review fires when a review is first seen; the publish moment is not observed.
• updated_channel: No event is sent when a connected account’s settings change.
• activate_channel, deactivate_channel: Use new_channel and disconnect_channel.
• booking_invalid_guarantee: Cards are not validated on arrival.
• airbnb_notification: Airbnb platform notifications are not relayed.
• booking_unmapped_rate: Accepted, but not produced yet.

Bookings

The revision feed works as on Channex. A booking webhook carries booking_id, property_id and revision_id, and the revision exists before the webhook is sent, so the loop needs no change: receive the webhook, fetch the revision, store it, ack it.

# 1. Fetch the revision named by the webhook
curl "$BASE/booking_revisions/REVISION_ID" -H "user-api-key: sk_live_YOUR_KEY"

# 2. Acknowledge it once stored
curl -X POST "$BASE/booking_revisions/REVISION_ID/ack" -H "user-api-key: sk_live_YOUR_KEY"

# Catch-up: every revision not yet acknowledged
curl "$BASE/booking_revisions/feed" -H "user-api-key: sk_live_YOUR_KEY"

• booking_new, booking_modification and booking_cancellationfollow the revision's status, so a cancellation always arrives as booking_cancellation.
• A change that leaves the booking's content unchanged creates no revision and sends no webhook. non_acked_booking fires for revisions left unacknowledged, and is dropped if you ack first.
• A revision shows the booking's current content. Revisions are kept for 90 days; ack is idempotent.
• amount is null when the channel reported no money, never "0.00". The booking's guarantee carries the card where the channel provides one; no PCI app is needed. Webhooks never carry a card.
• reservation_request, accepted_reservation and declined_reservation carry bms in the booking revision structure.

Booking CRS

POST /bookings and PUT /bookings/:idcreate and change real reservations, which appear in the feed as CRS revisions. One room per booking: send a multi-room booking as one booking per room. The stay is priced by the property's rates; if your days total differs, the response names both amounts in meta.warnings. Fields such as meta, services, deposits and notes are stored and read back as written.

Messages and reviews

/message_threads, /message_threads/:id/messages, /bookings/:id/messages, /attachments, /reviews, /reviews/:id/reply and /scores work as on Channex, with message, review and updated_review webhooks. Replies go out on the channel the guest wrote on. The limits are in the table below.

Endpoint coverage

Every operation in Channex's published API has a route. Full behaves as on Channex. Partial works, with the limit named. Not available returns a Channex-shaped error with the reason, never a fake success. A value Repull does not hold is null, never 0, false or [].

Differences to know

• Revision ids start fresh. When you import a Channex account, property, room type, rate plan, webhook and channel ids carry over; booking revision ids do not. Unacknowledged Channex revisions should be acked on Channex before you switch.
• New channels start deactivated. A channel you create is not pushed to until you call activate.
• Airbnb and Vrbo sell one rate. Extra rate plans reach Booking.com when mapped to a Booking.com rate; on Airbnb and Vrbo the primary plan sets the price.
• No card charging. Cards are readable on the booking; charge, pre-authorise, settle, void and refund are not available.
• Rate limits are Repull's. A 429 returns http_too_many_requests with Retry-After. See Rate limits.