generated: '2026-09-02' method: searched source: >- openapi/apiable-platform-api-openapi.json; https://www.apiable.io/security/; https://www.apiable.io/docs/automation/webhooks/; https://trust.apiable.io/ standards: - id: openapi-3.1 conforms: true evidence: >- openapi/apiable-platform-api-openapi.json declares openapi 3.1.0 with 42 paths, 66 operations, 62 component schemas, unique operationIds on every operation and a summary on every operation. - id: oauth2 conforms: true evidence: >- components.securitySchemes.oauth-cc is type oauth2 with a clientCredentials flow and a tokenUrl; every one of the 66 operations carries an explicit security requirement. - id: oauth2-client-credentials conforms: true evidence: RFC 6749 §4.4 flow, tokenUrl https://developer.apiable.io/api/oauth2/token - id: oidc conforms: partial evidence: >- Apiable does not operate an identity provider. Customer portals federate to a customer's own OpenID Connect provider (Entra ID, Google, Okta, Cognito, Auth0, Keycloak). Source https://www.apiable.io/security/ and /docs/integrations/identity-providers/oidc/. The Platform API itself exposes no openIdConnect scheme and no OIDC discovery document. - id: standard-webhooks conforms: true evidence: >- Apiable signs every webhook delivery with the Standard Webhooks scheme — webhook-id, webhook-timestamp and webhook-signature headers, HMAC-SHA256 over {webhook-id}.{webhook-timestamp}.{raw-body}, v1, signature list, 5-minute replay tolerance. Documented at https://www.apiable.io/docs/automation/webhooks/ and mirrored in the org's public standard-webhooks repository (https://github.com/apiable/standard-webhooks). - id: rfc9457-problem-details conforms: false evidence: >- No response in the spec uses application/problem+json; all 182 response content declarations are application/json and no error schema component exists. - id: json-api conforms: false - id: odata conforms: false - id: scim conforms: false evidence: >- User, Team and Company resources exist but on bespoke paths (/api/users, /api/teams, /api/companies) with no urn:ietf:params:scim:schemas:* URN and no /Users or /Groups endpoint. - id: fhir conforms: false evidence: >- Apiable markets a healthcare vertical (/healthcare/) for scope management and Dynamic Client Registration under US health-IT rules, but the Platform API defines no FHIR resource shape. - id: fapi conforms: false - id: psd2 conforms: false - id: iso-27001 conforms: false status: in-progress evidence: >- https://www.apiable.io/security/ states "ISO 27001 in progress (2026)". A Vanta-hosted Trust Center is live at https://trust.apiable.io/. Recorded as in-progress, NOT as certified. - id: gdpr conforms: true evidence: >- https://www.apiable.io/security/ states GDPR-compliant; hosting is AWS eu-central-1 (Frankfurt), single-tenant per customer, with a published subprocessor list at https://www.apiable.io/terms/subprocessors/. - id: aws-well-architected conforms: true evidence: >- https://www.apiable.io/security/ states the AWS Well-Architected Framework Review was passed in 2025 as an AWS Partner Network ISV. domain_standard: market: API portal / API management platform declared_in_contract: null note: >- REWARD-ONLY, and nothing to reward here. There is no domain standard for the API-portal market that a contract can declare — no SCIM URN, OData $metadata, OpenRTB endpoint, Sparkplug namespace, LTI/OneRoster shape, OAI-PMH verb or HL7/X12/ISO-20022 message type appears in the Apiable Platform API, and none would be expected. Standard Webhooks (above) is the closest cross-cutting standard the contract actually implements and is recorded as its own entry. compliance_program: published: true url: https://www.apiable.io/security/ trust_center: https://trust.apiable.io/ certifications_achieved: [AWS Well-Architected Framework Review (2025)] certifications_in_progress: [ISO 27001 (2026)] regimes: [GDPR] data_residency: AWS eu-central-1 (Frankfurt); additional regions for enterprise customers tenancy: single-tenant portal instance with its own database per customer