API Reference
OpenAPI-generated reference for the public Agiled API.
The docs app renders generated OpenAPI reference pages for the public Agiled API. Use those generated pages for endpoint parameters, request bodies, response schemas, and examples.
Use the API from trusted backend systems, automation platforms, and internal services. Do not expose API keys in browser code, mobile apps, public scripts, or customer-facing pages.
What to Build with the API
Use the public API for backend syncs, reporting exports, internal tools, automation platforms, and controlled data imports. Common examples include creating contacts from another system, syncing invoice status to a data warehouse, attaching files from an operations workflow, or listening for webhook events after records change.
If a workflow can be handled inside Agiled with workflows, forms, imports, or integrations, use the built-in feature first. Use the API when the source system or business process needs a custom integration.
API Base Path
Public REST endpoints are mounted under:
/public/v1The API settings page shows the full API base URL for the current environment.
Store the base URL and token as environment variables in your integration so test, staging, and production systems do not accidentally call the wrong workspace.
Authentication
Send API requests from a trusted server with the API key configured in an environment variable or secret manager. Rotate keys when a teammate leaves, a server is replaced, or a key may have been exposed.
Do not paste production keys into client-side scripts, shared browser snippets, public repositories, or support tickets.
Generated Reference
OpenAPI pages are grouped by API tag in the docs navigation. If you cannot find an endpoint by title, use docs search or inspect the generated API section under the docs sidebar.
Recommended Workflow
- Create a scoped API key.
- Test
GET /public/v1/me. - Read the generated reference for the resource you need.
- Test a list endpoint with a small page size.
- Add filtering, includes, and idempotency where needed.
- Test one write request before enabling bulk sync.
Integration Checklist
Before turning on a live integration:
- Use a dedicated API key for that integration.
- Log request IDs, status codes, and response bodies for failures.
- Keep retry logic bounded so one failure does not create duplicates.
- Store external IDs when syncing records between systems.
- Test rate-limit and validation errors.
- Document who owns the integration and where its credentials live.
Troubleshooting
If every request fails, confirm the base URL, API key, and authorization header.
If list endpoints work but writes fail, check required fields, enum values, and workspace permissions for the key.
If duplicate records appear, add external ID mapping or idempotency logic before running another bulk sync.