You've got a good starting list, especially the caution on Freshsales' tiering. I'm in a similar boat, evaluating for a manufacturing team of about 18. The point about a documented API is what I keep circling back to.
The real test I've found isn't the documentation, it's the error messaging. A poorly documented API might just be annoying, but vague 429 or 500 errors from their webhooks during a high-volume sync can stall an entire operation. Have you considered asking for their API status page or historical uptime logs for the integration endpoints specifically? That's been more telling for me than the docs.
On your "clear per-user pricing" requirement, I noticed you didn't mention anything about concurrent user sessions. Some platforms define a "user" as a named license, but others restrict how many can be actively using the API at the same time under that license. For a 20-person team running syncs, that could force you into a higher tier disguised as an "add-on." Have you seen that in your trials yet?
That's a great point about error messaging versus documentation. I hadn't thought to ask for the API status page specifically, but it makes sense. A clean docs page is easy to build; reliable webhook delivery under load is a different story.
Your note on concurrent sessions hits close to home. I saw a trial where a platform's "user" was a named login, but their API license for the integration was separate and capped at two concurrent connections. For a team our size running automated sequences, that's a non-starter. Have you found a reliable way to test for that before signing, other than just asking sales? They often don't know the technical limits.
You test it. Build a small PoC during the trial that mimics your worst-case concurrent load and monitor for connection drops or throttling headers. Sales reps rarely have the engineering context, but a stress test against the staging or trial environment reveals the real limits.
For the API status page, look for one powered by a third-party like Statuspage or Atlassian. Internally-managed "status" sites often lack granular incident history. The key metric is mean time to recovery for integration-specific endpoints, not just overall platform uptime.
On concurrent sessions, the licensing fine print is usually buried. Search their knowledge base or community forum for "API pool" or "connection limit". That's where the real constraints get discussed by frustrated developers, not in the sales collateral.
Good call on checking the knowledge base for 'API pool'. I'd add vendor security questionnaires to that list. If they list a third-party status page provider in their SOC 2 report, it's a good sign their incident response process is formalized. If they can't produce a report, treat their status page as marketing.
A PoC test is mandatory, but confirm the trial environment's rate limits match production. I've seen vendors throttle trial instances harder, which masks the concurrency wall you'll hit day one.
Where is your SOC 2?