A Public API for the Data Your Team Already Uses
Read and write business data from external systems through a public REST API with workspace-aware access control.
Let other systems work with InfoLobby records without bypassing the app, permissions, or audit context.
The practical problem
Many no-code and internal-tool products trap data behind private endpoints or awkward exports. That makes serious integrations harder than they should be.
InfoLobby includes a public REST API for spaces, tables, records, comments, files, and tasks. External systems can work with your data through standard HTTP endpoints while your team keeps using the same platform internally.
The API should extend the system, not create a shadow system.
When external tools need access, direct database credentials are tempting but messy. InfoLobby's API gives integrations a public surface while internal users keep working in the app against the same records.
- Use bearer tokens with workspace-aware access
- Work with records, comments, files, tasks, spaces, and tables
- Keep external writes inside the same operational trail
What changes for the team
- Public REST API for core data operations
- Bearer token auth with workspace-scoped access
- Read-only mode and IP whitelisting support
- Rate limits sized by plan
What InfoLobby gives you
- Create and manage spaces, tables, records, comments, files, and tasks
- Connect external apps without custom DB access
- Use the same platform for both internal work and system integrations
- Pair API usage with audit history and automations inside the app
How teams usually start
- Create an API key with the workspace access and restrictions the integration actually needs.
- Use public endpoints for spaces, tables, records, comments, files, or record-scoped tasks.
- Keep internal users in the app while external systems read or write the same operational data through HTTP.
Best fit
- Teams that need external systems to safely read or write InfoLobby data
- Customer portal bridges, reporting pipelines, sync jobs, and custom scripts
- Integrations that should respect workspace access rather than raw database credentials
Probably not a fit
- Developers who only want direct SQL access to a hosted database
- Public consumer APIs where InfoLobby is not the system of record
- Third-party sync
- Customer portal bridges
- Custom scripts
- Reporting pipelines
FAQ
What can the public API manage?
Core endpoints cover spaces, tables, records, comments, files, and tasks, with authentication and rate limiting built in.
Is the public API separate from internal ajax endpoints?
Yes. Public data operations use dedicated API endpoints rather than app-only ajax calls, which makes integrations more stable and explicit.
Need this without adding another fragmented tool?
InfoLobby works best when the data, process, and collaboration belong together. If that is your bottleneck, a trial will show fit faster than another abstract product tour.