Give your integration access
Administrators create keys with only the actions an integration needs. Keys expire, can be revoked, and remain limited by their owner’s current workspace permissions.
Make your first request
Run requests on your server. Replace sample IDs and recipients; POST requests can send real messages.
List official channels
https://botmust.com/api/v1/channelsFind the Botmust channel ID. No Meta credentials are returned.
curl --fail-with-body --request GET \
"https://botmust.com/api/v1/channels" \
--header "Authorization: Bearer $BOTMUST_API_KEY" \
--header "Accept: application/json"Retries, limits and response states
Use a different Idempotency-Key for each new POST operation. Retry the same operation with the same key and identical JSON. A saved response is replayed with Idempotency-Replayed: true. Keys are scoped to the workspace and endpoint, including across API key rotation. Changing a payload requires a new operation key, even after a saved validation error.
Message requests return HTTP 202 with request_id and status: queued. Poll that ID for submitted, failed or needs_review. A submitted request is not proof of delivery. Use delivery_status or signed message.status events.
For needs_review, check provider delivery records before creating another send. Botmust will not automatically resend an uncertain request. Polling can resolve a later delivered/read status even while the original request remains held for review.
Limit: 120 authenticated requests per minute per workspace, plus a 240/minute IP limit. Respect Retry-After on HTTP 429. HTTP 401 means invalid access, 403 means insufficient permission, 404 means unavailable record, 409 means conflicting operation/state and 422 means invalid input or unavailable sending conditions.
Receive updates in your tool
Forward selected events to your server. Incoming messages and contact events include customer data. Internal team notes are excluded. Use a destination you control; it must use HTTPS on port 443 and resolve to public IPv4 addresses.
Verify signatures and prevent duplicate processing
Read the exact raw request body. Calculate HMAC-SHA256 of timestamp + "." + rawBody using your signing secret. Compare in constant time with the hex value after sha256= in X-Botmust-Signature. Reject timestamps more than five minutes old. The timestamp is in X-Botmust-Timestamp, in Unix seconds.
Persist X-Botmust-Event-Id before processing. Return 2xx for an already processed event. Delivery is at least once; retries use the same event ID and body with a fresh timestamp/signature. Events may arrive out of order: compare their created_at and reconcile with the API.
The scheduler dispatches events each minute. Non-2xx responses and connection failures retry up to eight attempts, with increasing delays up to one hour. Redirects are not followed. Disabled endpoints cancel queued deliveries. An already in-flight request may complete.