8 questions from the RFI stage, free
These come from the module as sold. The workbook adds follow-ups, a response format, a weight and a score column to each.
1. Do you provide a public API for core product functionality? If so, provide the URL to the public API reference documentation.
Why it matters. A public, documented API is the baseline for enterprise integration. Without it, buyers are locked into the vendor UI and cannot automate workflows or integrate with internal systems.
- Confirms a public API exists and provides a direct URL to reference documentation.
- Documentation is comprehensive, covering authentication, error codes, and example requests.
- Core product capabilities are exposed via the API at parity with the UI.
- No public API exists.
- API access is gated behind sales conversations or a non-disclosure agreement (NDA).
- Documentation is incomplete, outdated, or requires a login to view.
2. Do you support SAML 2.0 and/or OpenID Connect (OIDC) for single sign-on (SSO)? List the identity providers (IdPs) for which you have formal documentation or tested integrations.
Why it matters. Enterprise SSO is a non-negotiable security requirement. Vendors must support at least one of the two prevailing standards (SAML 2.0, OIDC) and provide clear documentation for integration with major IdPs like Okta, Microsoft Entra ID, and Google Workspace.
- Supports both SAML 2.0 and OIDC.
- Provides links to step-by-step integration guides for major IdPs.
- Supports Service Provider (SP)-initiated login, and IdP-initiated login can be disabled per tenant.
- SSO is only available on a premium pricing tier (an "SSO tax").
- Support for SAML or OIDC is partial, non-standard, or in beta.
- Integration is only documented for one specific IdP.
3. Provide a table of your official SDKs and client libraries. Include columns for: Language, Package Manager URL, and Source Code Repository URL.
Why it matters. Well-maintained SDKs in major enterprise languages (e.g., Python, TypeScript, Java, .NET) significantly reduce integration time and bugs. Publicly-hosted, open-source SDKs allow buyers to inspect behavior and assess quality.
- Provides a table with official SDKs for major enterprise languages.
- Source code for all SDKs is hosted on a public platform like GitHub.
- SDKs are published to standard package managers (e.g., npm, PyPI, Maven).
- SDKs are only provided for one or two languages.
- SDKs are thin, auto-generated wrappers with poor ergonomics.
- Source code repositories are stale, with no recent commits or issue responses.
4. Provide a table of your prebuilt connectors to common enterprise systems. Include columns for Target System, Category (e.g., CRM, ITSM), Support Level (Vendor or Community), and a link to documentation.
Why it matters. Prebuilt connectors can significantly shorten time-to-value, but their quality and support level vary widely. Buyers need a clear inventory of available connectors with an explicit statement of support.
- Provides a comprehensive table or link to a public connector catalog.
- Clearly distinguishes between vendor-supported and community-maintained connectors.
- Documentation for each connector details its capabilities, authentication methods, and known limitations.
- A long list of integrations is advertised, but most are marked as 'coming soon' or are partner-built with no vendor SLA.
- The distinction between vendor-supported and community connectors is unclear.
- Connectors are poorly documented or lack basic configuration details.
5. Describe your API versioning policy. Include details on: a) How API versions are indicated in requests (e.g., URL path, header). b) The minimum support window for older versions.
Why it matters. Enterprise integrations have multi-year lifecycles. An unstable API with short deprecation windows imposes recurring rework costs and risk. A clear, published policy on versioning and breaking changes is a precondition for safe enterprise dependency.
- A clearly defined versioning mechanism (e.g., URI, header).
- A documented minimum support window for older versions, stated as a number of months.
- A public, easily accessible policy document is provided.
- No formal versioning or deprecation policy exists.
6. Do you support SCIM 2.0 for automated user lifecycle management? If so, which SCIM resources and operations (e.g., create/update/deactivate Users, manage Groups) are supported?
Why it matters. SCIM is the standard for automating user provisioning and de-provisioning. Incomplete SCIM support (e.g., supporting user creation but not de-provisioning, or not syncing group memberships) creates security gaps and manual administrative overhead.
- Confirms support for the SCIM 2.0 protocol.
- Supports both /Users and /Groups endpoints.
- De-provisioning events correctly and promptly revoke active sessions and access tokens.
- No SCIM support; provisioning requires manual user management or CSV uploads.
- Group memberships are not synced, requiring manual role mapping within the application.
- De-provisioning only marks a user as inactive but does not terminate their active sessions.
7. What is your support policy for older major versions of your SDKs, especially regarding security patches and continued compatibility with current API versions?
Why it matters. Enterprises cannot constantly update their dependencies. A vendor should have a clear policy defining the support window for major SDK versions, including a commitment to provide security patches even after feature development has ceased.
- A stated minimum support window per major SDK version.
- Security patches are backported to all supported versions.
- A compatibility matrix between SDK versions and API versions is published.
- Only the latest version of the SDK is officially supported.
- No policy for backporting critical security fixes.
- The compatibility matrix between SDK and API versions is not published.
8. For your prebuilt connectors, what authentication mechanisms are supported for connecting to target systems (e.g., OAuth 2.0, service accounts, API key), and how are credentials stored securely?
Why it matters. A connector is only as secure as its credential handling. It must support modern authentication protocols like OAuth 2.0 and store any secrets (like API keys) in an encrypted, isolated manner. Insecure credential storage is a major security risk.
- Supports modern authentication methods like OAuth 2.0 where available on the target system.
- Credentials are encrypted at rest using strong algorithms in a dedicated secret store.
- Credentials and tenants are logically and physically isolated.
- Connectors only support outdated methods like basic authentication (username/password).
- Credentials are stored in the primary application database without proper encryption or isolation.
- The vendor provides no documentation on credential storage practices.
What the audit changed
A language model drafted these questions and a second model critiqued them. Three audit passes followed and made 128 changes. Three examples:
Wrong or outdated citation
Draft: Provides standard 'RateLimit-*' or 'X-RateLimit-*' headers exposing the limit, remaining requests, and reset time.
Now: Provides response headers exposing the limit, remaining requests, and reset time (e.g., the widely used 'X-RateLimit-*' headers, or the 'RateLimit' and 'RateLimit-Policy' fields in the IETF draft).
Neither is a published standard. 'X-RateLimit-*' is a convention. The IETF work, draft-ietf-httpapi-ratelimit-headers-11 (May 23, 2026), is still an Internet-Draft, not an RFC, and defines 'RateLimit' and 'RateLimit-Policy' fields; 'RateLimit-Limit/-Remaining/-Reset' were names in earlier drafts. Source: https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
Wrong or outdated citation
Draft: Missing or non-standard headers force
Now: Missing or undocumented headers force
Pass 1 established that no published standard defines rate-limit headers: 'X-RateLimit-*' is a convention and the IETF 'RateLimit' fields are still an Internet-Draft (draft-ietf-httpapi-ratelimit-headers-11, May 23, 2026). Retry-After is standard (RFC 9110 Section 10.2.3). Source: https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
Wrong or outdated citation
Draft: The sandbox has separate, often more generous, rate limits for testing.
Now: States the sandbox rate limits and whether they are separate from production limits.
'Often more generous' is unsourced and conflicts with mod.integration.rfp.012, which preferred lower sandbox limits. No standard sets a direction; the buyer needs the stated figures.
