The FileMaker HTTP Server is the part of the FileMaker Server architecture that makes its web-based services available through HTTP and HTTPS.
It provides the entry point used by services such as:
- FileMaker WebDirect
- FileMaker Data API
- FileMaker OData API
- Custom Web Publishing
- FileMaker Server Admin Console
- Container data accessed through secure URLs
The expression “FileMaker HTTP Server” does not refer to a development environment comparable to FileMaker Pro. It describes the HTTP communication layer through which browsers, web applications, APIs, and administrative tools reach the appropriate FileMaker Server components.
From an HTTP request to FileMaker
When an application sends an HTTPS request to FileMaker Server, several components may be involved.
The installed web server receives the request first. Depending on the operating system and configuration, this may be Apache, Microsoft IIS, or Nginx.
The request is then routed to the appropriate FileMaker service:
- WebDirect requests are handled through the Web Publishing Engine.
- Custom Web Publishing requests are handled through the Web Publishing Engine.
- Data API requests are handled by the Data API Engine.
- OData requests are handled by the OData service.
- Admin Console requests are directed to the FileMaker Server administration services.
The HTTP layer is therefore the front door, while the requested FileMaker service performs the actual application work.
HTTP and HTTPS
Although HTTP describes the protocol family, production FileMaker Server deployments should use HTTPS.
HTTPS encrypts communication between FileMaker Server and browsers, API clients, or other applications. It also allows clients to verify that they are communicating with the expected server.
This requires a valid SSL certificate matching the server’s hostname. Using the FileMaker default certificate may be acceptable for initial testing, but it does not provide the identity verification expected from a production service.
At fmcloud.fm, every hosted FileMaker Server receives a valid hostname and SSL certificate. Certificate deployment and renewal are automated, allowing FileMaker web services and APIs to remain securely accessible without requiring customers to manage certificates manually.
The importance of the hostname
HTTP-based FileMaker services should be accessed through the server’s fully qualified domain name rather than its raw IP address.
The hostname is used for:
- SSL certificate validation
- OAuth redirection
- Secure API connections
- WebDirect access
- Links to container data
- Communication between FileMaker Server components
Changing a hostname after deployment can therefore affect more than the address users type into their browser.
Ports 80 and 443
FileMaker Server normally uses the standard web ports:
- Port 80 for HTTP
- Port 443 for HTTPS
Port 80 may redirect users toward a secure HTTPS connection. Port 443 is the principal public entry point for modern FileMaker web services.
These ports must be available during installation. Another website or service cannot normally occupy them on the same address without an appropriately designed proxy architecture.
The native FileMaker network protocol used by FileMaker Pro and FileMaker Go is separate and normally uses port 5003.
Not the same as the Web Publishing Engine
The HTTP Server and the Web Publishing Engine have different responsibilities.
The HTTP layer accepts web requests and routes them. The Web Publishing Engine interprets FileMaker layouts, sessions, scripts, and user interactions for WebDirect and Custom Web Publishing.
Similarly, the Data API and OData have their own processing components behind the HTTP entry point.
Understanding this separation is useful when diagnosing a problem. A working HTTPS connection does not necessarily mean that the requested FileMaker service is running correctly.
FileMaker HTTP expertise from fmcloud.fm
A reliable FileMaker web deployment involves DNS, SSL certificates, ports, firewalls, reverse-proxy behavior, FileMaker connectors, and the application itself.
At fmcloud.fm, these components are managed as a complete hosting architecture. We can diagnose whether a connection problem originates in the certificate, web server, HTTP routing, FileMaker service, authentication configuration, or custom app.
This is particularly valuable for applications using WebDirect, OData, the Data API, or Custom Web Publishing, where several layers must work together before a request reaches the FileMaker database.
