Security and compliance

This page lists the security mechanisms Apiable implements, each tied to how the platform works. Apiable is a control plane: it secures the access it provisions on your gateway and authorization server, protects the credentials it handles, and records what changed. For formal compliance documentation, contact Apiable.

How does Apiable store credentials?

In AWS Secrets Manager. When you connect an authorization server, the client IDs and secrets you provide are written to Secrets Manager, not saved on the configuration record stored in the database. They are read back only transiently when an operation needs them.

This applies to the Dynamic Client Registration and admin credentials for an authorization server integration. The stored record keeps non-secret configuration such as the server URL and connection status, while the secrets live in Secrets Manager. The same pattern keeps gateway credentials out of plain entity storage.

Does Apiable support multi-factor authentication?

Yes, for your API Portal. On the portal security page you set MFA to one of three states, and the setting controls whether your developers must, may, or cannot use a second authentication factor when they sign in.

Changing MFA is limited to users with the manage-portals permission, and the control reconciles the live state from your portal's identity provider so it reflects what is actually in force. See Portal security and MFA for the full flow.

Does Apiable keep an audit log?

Yes. The audit log records changes across your dashboard and your API Portal, in separate Dashboard and Portal tabs. You can filter by actor, by event type, and by time range, and expand a row to see the detail of a change.

Sensitive values are stripped from the detail view. The audit log removes fields matching password, secret, token, key, and credential, so secrets are not displayed in the history. See Audit log for filters and event categories.

Are Apiable's outbound webhooks signed?

Yes. Outbound webhooks are HMAC-SHA256 signed, following the Standard Webhooks specification. You verify each delivery with the signing secret, so you can confirm a webhook genuinely came from Apiable and was not tampered with or replayed.

Each outbound webhook carries three headers and a versioned signature:

Because the format follows Standard Webhooks, you can verify deliveries with any Standard Webhooks library.

How is SSL handled for custom domains?

Apiable provisions SSL certificates through AWS Certificate Manager using DNS validation. When you add a custom domain, Apiable requests the certificates and generates the CNAME records you add at your DNS provider. The certificate is issued before your portal switches over.

You do not upload or manage certificates yourself. See Custom domain for the step-by-step flow and the validation states.

How is API access secured?

Through scoped OAuth2 access enforced on your own gateway. Apiable provisions an OAuth client per subscription, your authorization server issues a token carrying the granted scopes, and your gateway checks the token against each endpoint before the request reaches your backend.

Scope-based access control runs with Keycloak and Auth0 today. A gateway either issues OAuth natively or binds an external Authorization Server that issues and validates tokens. Because the gateway enforces scopes at request time, the access boundary lives on your infrastructure, not in a proxy. See Access control and The no-proxy model.

What about compliance certifications and audits?

Contact Apiable for current compliance documentation. This page describes the security mechanisms the platform implements rather than listing specific certifications or audit results.

Where to next