Real file validation
Check extension, declared MIME type, detected MIME type and file signature before accepting content.
Capability
Security and access control
Protect files and services with permissions, OTP, external authentication, restrictions and publication windows.
Overview
Protect files and services with permissions, OTP, external authentication, restrictions and publication windows.
Features
What Security and access control can do
Private and public visibility
Keep resources private by default and expose only items explicitly configured for public access.
Access for users and groups
Share administration or content with identified Apification users and reusable permission groups.
One-time password access
Require an OTP sent through the configured channel before allowing protected participation.
External authentication
Delegate identity checks to supported external providers when a service requires an existing account.
Publication windows and restrictions
Limit access with start and expiry dates, capacity, participation rules and service-specific conditions.
Signed integrations and secrets
Protect embedded access and webhooks with scoped credentials, signatures and server-side secrets.
Evidence and audit context
Retain relevant events, identities, timestamps and technical results for traceable processes.
Access decision
Resolve identity, resource and purpose together
Every exposure decision starts from private content and adds only the access required by the workflow.
-
01 Classify the resource
Validate its real type, ownership and sensitivity before enabling actions.
-
02 Identify the audience
Choose account users, groups, authenticated participants or public visitors.
-
03 Apply restrictions
Set permissions, publication windows, capacity and service-specific conditions.
-
04 Review evidence
Use events, identities and technical results to investigate important actions.
Operational detail
How Security and access control works in practice
Security is applied in layers across content validation, account identity, resource permissions, public-service restrictions and signed integrations rather than through one global visibility switch.
Controls operate at different layers
Account roles govern administration, resource permissions govern collaboration, visibility governs publication and service rules govern how a public interaction can occur.
Secrets stay outside public clients
API credentials, webhook secrets and iframe-signing material belong on trusted servers; browsers receive only scoped or short-lived context.
Public does not mean unrestricted
A published form, event or signature process can still require identity, dates, capacity, one-time access and other conditions suited to the service.
Evidence supports accountable operation
Relevant timestamps, actors, delivery results and state changes help explain what happened, while retention and business interpretation remain shared responsibilities.
Frequently asked questions
Questions about Security and access control
No. Visibility, publication, user access, and public links are separate controls that must be configured explicitly.
Depending on the service, you can require OTP or external authentication and restrict dates, capacity, responses, or participant conditions.
OAuth protects provider connections, API credentials authenticate requests, and signed webhooks let receivers validate deliveries.
Moving changes organization, not the identity of the item. Its ownership and access settings remain associated unless they are changed explicitly.
No. Authenticated user or group access and public visibility are separate controls with different audience and administration implications.
Apification exposes the records supported by each service, while the account owner must align retention, exports and legal interpretation with its own obligations.