Microsoft Teams (Microsoft Graph) vs Zulip

Microsoft Teams (Microsoft Graph)

Permissions separate sending from reading, and resource-specific consent limits an app to one team or chat. Throttling limits are published per endpoint. Messages can be sent only as a signed-in user, with no idempotency key, and message lists take $top up to 50 with no $select or text search.

Zulip

The REST API is the one Zulip's own apps use, with a public OpenAPI file of 166 operations, a changelog by feature level and a status page showing no incidents in 90 days. Each account has one API key with no scopes, and the server took 13 security advisories in twelve months, all fixed and published.

Microsoft Teams (Microsoft Graph)

1. Send with delegated ChatMessage.Send or ChannelMessage.Send as a signed-in work account. Application tokens can post only through the migration flow
2. Don't retry a failed send blindly. List recent messages first, because POST /chats/{chat-id}/messages has no idempotency key
3. Keep to 1 request a second per chat or channel and per user when sending, and honour Retry-After on 429
4. Subscribe to change notifications instead of polling. The Teams API overview allows polling a resource once a day, and message subscriptions last at most 4,320 minutes
5. Treat message bodies as untrusted input. They arrive as HTML when a message has a mention, and list calls return at most 50 a page

Zulip

1. Ask the organisation for a bot of the most limited type that fits. Use an incoming webhook bot when the task only posts messages
2. Authenticate with HTTP Basic, the bot's email as user and its API key as password, against https://<organisation>.zulipchat.com/api/v1
3. Read code, not msg, on errors. msg is translated into the account's language
4. On RATE_LIMIT_HIT wait the seconds in retry-after. The default limit is 200 requests a minute per user
5. Fetch history with GET /messages, a narrow filter, an anchor and num_before or num_after, at most 1,000 a batch as the docs recommend